Misadventures in GUI package-building

In recent weeks I have begun to delve into the exciting world of packaging — mostly to work on font packages, which are among the simplest bits of software that one can install. The dependencies and possible conflicts are few, the payload is small, and getting the package metadata right is arguably the most important part of the process. When I spotted a news item in my feed reader about a "GUI package creator," I was curious enough to take it for a test drive. The experience itself was underwhelming, but after some digging around what I found truly perplexing is that this is an application category that seems to continually spawn new, independent development efforts, all of which result in short-lived projects.

First run

The application that I first took notice of is called Ubucompilator, a GTK+ front end for creating and modifying Debian packages. In spite of the name, it is not Ubuntu-specific, and can help you create packages for any Debian-based system. Ubucompilator has been in development since December 2009, but made its 1.0 release in May 2011, which sparked a flurry of news items in the Ubuntu blog circles.

The bulk of those stories linked to a short YouTube video showing the program in action at the hands of its creator. Unfortunately, however, the video includes no narration, which makes it difficult to follow the on-screen action (shrunk down to YouTube size as it is). There is also no documentation available, either at the main project domain or at the Who's Who of hosting services where Ubucompilator maintains a presence: Google Code, Launchpad, SourceForge, Softpedia, and WordPress.com.

The Launchpad project pages have the most recent builds of the code, the 1.0 source package from May. It requires a runtime for Gambas2, the Visual-Basic-like language, and compiles cleanly with GNU autotools. The interface consists of a filesystem browser on the left, a textarea on the right, and a series of labeled buttons beneath, reading: "Autogen," "./Configure," "Make," "Make install," "Dh_make," "edit control file," and "Make .deb." Just above the bottom row sits a text-entry field labeled "email."

The aesthetics of the interface received more than a fair share of criticism from commenters in the blog stories. Setting that aside, what Ubucompilator appears to actually do is allow you to navigate to a directory containing buildable source code (such as an unpacked upstream package), and punch through the basic build steps with button clicks rather than shell commands. The output of each command is piped into the textarea on the right hand side of the window.

From the perspective of a packaging-newbie, I can see some value to this approach. Obviously, the configuration and make steps are there for convenience's sake only, because if the package fails to compile, you must debug and fix it using other tools. But it ought to be assumed that any user who knows how to use GNU autotools is already familiar with these steps. On the other hand, packaging is another process entirely, so how (and, more importantly, when) to make use of dh_make may not be intuitive.

Unfortunately, this is the stage of the process where Ubucompilator breaks down. Using dh_make to convert the working source code directory into a properly Debian-formatted form requires making some changes and calling some package-dependent options, and Ubucompilator does not expose any of this functionality. In addition, the "edit control file" button simply opens the ./debian/control file (only if it already exists) in an external editor. Building the actual Debian package (for which Ubucompilator calls dpkg-buildpackage) may also require passing arguments, which is not configurable in the interface.

The result is that Ubucompilator is useful for making modifications to a source package that is already in canonical Debian form, but it does not simplify the process of building anything new, nor help with the potentially-tricky steps like determining dependencies and fixing permissions. However, as commenter mikeru observed on one blog post, the bigger problem is that the interface does not reflect the ordered steps that a user must walk through in order to build a valid package. In Ubucompilator's toolbar-like layout, all of the commands are accessible at the same time, although in order to function, they must be executed in a fixed sequence. A "wizard"-like approach would better reflect the workflow and be more effective.

Other players

Interestingly enough, the "guided steps" approach that mikeru advocated is taken by at least two other GUI Debian-package-creator tools: Debreate and Packin. Nevertheless, neither of those two projects are still actively developed. Both are still installable and at least partially usable on a modern desktop, however, so I decided to explore them to see how they compared.

Debreate is a Python application that wraps a GUI around most of the same functionality as Ubucompilator, with optional support for problem-detection using Lintian, and Debian-to-RPM conversion with Alien. The last release was 0.7alpha6 from September 2010.

Debreate splits the package-construction process into discrete steps, with one page devoted to each and forward/back buttons to navigate between them. Its visuals border on the headache-inducing thanks to some odd color choices (alternating red and blue colored text fields and widgets), and not every page fits onto the default window size, but it does at least present all of the necessary options to the user, clearly labeled. It even allows you to preview how settings will be saved in the control file, and provides a decent interface for maintaining a package changelog, adding scripts, and creating .desktop menu entries.

You still need to have a basic understanding of Debian packaging in order to use Debreate, because there is little in the way of built-in help. I admit, it is probably impossible to provide a "help" menu entry that explains how to write pre- and post-install scripts, but some terminology (such as "pre-depends") would benefit from tooltips.

The same goes for the interface itself: it generally makes sense at first glance, but there are scattered checkboxes and radio-buttons whose immediate effects are unclear, particularly on those pages where there is a split-pane. For example, take the editable script window and the separate add/remove script buttons: by experimentation you learn to paste your script into the window and then click the "add" button, but there are plenty of GUI applications where you would be required to add the script before you could enter its contents; both are defensible.

Still, what Debreate does a good job of is visually tracking the settings that you make to a package-in-the-rough. For example, the "Files," "Scripts," and "Changelog" pages all include editors with which you can directly make changes. The other GUI packager-builders I looked at rely on calling external editing applications, and as a result, the changes that you make (including accidents) are not visible within the interface itself.

Packin is a Java application. The last release was in July 2009, and in an excellent display of irony, the Debian package on the download site is not installable, but I had no trouble extracting the .jar file within, and coaxing it to run under the OpenJDK runtime. Like Debreate, it adopts a step-by-step "wizard" approach to package construction, although it is significantly more compact. Not as many control file fields are supported, and you get only a single line to enter dependencies and conflicts (as opposed to Debreate's complete graphical tool with its fancy pull-down menu to select between =, >=, <=, and the other version-number operators).

It also does not have an interface to attach change-logs or scripts. Unlike Debreate, you do not add individual files or folders to the package — instead you point Packin to a properly-formatted directory. To take care of the other steps, you would still need to call on an external tool like debhelper. Between the two, Debreate is definitely the more complete tool, provided that you can read through the oddly-colored UI widgets well enough to use it.

Simplifying what can't be simplified

Debreate and Packin both require you to configure and successfully compile your source code before you begin building it into a Debian package. In that sense, the two of them and Ubucompilator stake off opposite ends of the process, and none of them covers it completely. There are potential uses for both. With Ubucompilator you could quickly patch an existing Debian package and rebuild it. With Debreate you can create a basic skeleton structure for a new package, taking advantage of the built-in guidance provided by the "wizard" approach. But neither one will work in a vacuum.

The naïve solution might be to suggest combining the two, but having spent some time with them, I am not convinced that a start-to-finish Debian package builder would have a market. The root of the problem is that even with an amalgam of Debreate and Ubucompilator's GUI tools, you will always need to drop out of the point-and-click environment to troubleshoot — either to debug the code or to edit scripts, permissions, and other package errors — and troubleshooting is inherently an un-simplifiable task. It is un-simplifiable because it consists primarily of the developer's own mental energy, and not repetitive processes that can be automated, or deterministic problems that can be caught and solved.

This is not news to anyone in the software engineering field, of course, but I was left wondering why so many people over the years have set out to build GUI interfaces for the task of package creation. Since the complete process cannot be reduced to point-and-click simplicity, eventually users become comfortable enough with the CLI and editor-based tools involved in the rest of the activity, and the GUI loses its appeal. It appears that each of the applications has a two-or-three year active lifespan before it slips into obscurity, yet new ones are always in development.

My guess is that packaging is perceived by people just starting out as having a significant barrier-to-entry, thanks to its box of specialized tools and its distinct nomenclature. To a new user, that can seem intimidating, but at the same time it is clearly a task that involves clear logic and understandable rules. Consequently, wrapping a GUI around them probably seems like a building a much-needed access ramp over that barrier — even though everyone who takes the ramp eventually no longer needs it. A similar argument could be made for other recurring "simplify it with a GUI" projects, such as graphical front-ends to version control systems, or graphical SQL explorers.

Ubucompilator, Debreate, and Packin could use some improvement, but ultimately I do not see anyone who gets into packaging using them for very long. Thus, rather than "how can we build the perfect GUI packaging tool?" perhaps better questions to ask are "how can we better integrate package-building into the development environment" and "how can we best cultivate new packagers?" The first question is up to the IDE- and SDK-makers to answer; the second is up to everyone, but the answer is probably a hard one — time, documentation, and an endless supply of patience to answer questions.