Author: Bruce Byfield
It’s a strong vision, although some of the details may prove controversial. It’s also one that Abiword, Inkscape, the GIMP, and at least three dozen other projects are already experimenting with. Commercial companies such as Adobe and VMware have also expressed interest, according to Hearn.
The rationale for Autopackage
Why develop a new package management system? After all, standards such as RPM, APT, and Gentoo’s Portage are already well-established. Nowadays, all of them can resolve package dependencies, and can run from graphical tools. Alternative systems are also widespread, including Conary, Sorcery, and Zero Install. Why not just modify an existing standard?
“Those formats have too much politics around them,” Lai explains. Just as importantly, Lai says, none of them equipped to deal with the differences between distributions. “A binary from one distribution doesn’t always work on another, because of things like glibc symbols and C++ ABI.” Nor are file locations and library names identical in different distributions. However, the real problem according to Lai, is that “Native package managers’ dependency detection depends on a database. Autopackage, on the other hand-detects dependencies by actually scanning for them.”
Besides these technical problems, the Autopackage team believes that managing system and desktop software together is a mistake. It requires developers to pay attention to desktop applications that are of secondary importance to them, and confuses end users with problems about dependencies and upgrades. Moreover, Hearn maintains, separating the two types of packages from each other potentially makes security easier. “If you can distinguish between third-party software and operating software,” he says, “then you can apply different levels of security privilege to those packages. A kernel package clearly needs full access to the system, whereas installing a chat program clearly doesn’t.”
Allowing ordinary users to install software is a new concept for GNU/Linux, but it’s one that the Autopackage team thinks is overdue. Hearn notes that the arrangement gives users some power over what they install without doing any harm to the system. With security precautions, administrators and developers can also use local installations as a sandbox for testing programs.
“If you’re a geek like me, then having two systems feels inelegant or dirty,” Hearn concedes. “That’s a natural feeling. But you have to stay focused on the end user. “We really do need to dump this one-size-fits-all approach to operating system design. It was a nice idea, it was tried, and it turned out to work well for servers and not so well for desktops.”
Using Autopackage
The Autopackage site includes a list of some of the programs available in Autopackage format. Besides a selection of well-known desktop applications, they include a GTK graphical manager for GNOME and a Qt graphical manager for KDE. Both have a close resemblance to the Add/Remove Programs window in Windows’ Control Panel, although they can only be used to remove installed programs. Only packages that include a .desktop file are displayed, so that, unlike with Kpackage or Synaptic, dependencies on libraries are not displayed.
Before using a package on the site, you must either log in as root or give execute permission to the current account. The site also suggests that you remove any copies of the same program installed by another means. If you are upgrading, you must remove the older version before installing the new.
Once these housekeeping keeps are taken care of, you can install packages from a desktop file manager by clicking and running them. A series of popup windows informs you of the installation’s progress. From the command line, you can install packages by changing to the package’s directory and entering:
bash [packagename].package
If you are running from a user account, you can enter the root password to make the program available from all accounts.
When the first package is installed, its scripts add the Autopackage executable to /usr/bin, as well as the configuration files in /etc/autopackage and other need resources. The config file sets whether packages can be installed to user accounts, and the default locations for system and local installations. The scripts also create the autopackage MIME type.
By default, programs installed with root privileges are placed in /usr/share. Those installed for a single account are placed in the .local folder in the account’s home directory. However, users can specify alternate locations from the command line by using the --prefix= switch. The Web site instructions for installation suggest a few basic locations for beginners.
To remove a package, select it from the Autopackage graphical manager, enter the root password if necessary, and click the Remove button. From the command line, enter:
package remove [package name]
The same command is used to remove autopackage itself:
package remove autopackage
When a package is removed, its dependencies remain. Hearn and Lai point out that dependencies are not always removed by some other package management systems, either. Nor, given current hard drive sizes, are remaining packages a problem — although they might be a security weakness. Still, package removal might be one area in which a database system with a list of each piece of software’s dependencies would have an advantage over Autopackage.
For developers, Autopackage offers a small toolkit. It includes BinReloc, a utility that allows an Autopackage to work with libraries located in different locations, and APBuild, a collection of programs for creating Autopackages.
Interface design
One detail that makes Autopackage stand out from many free and open source software projects is the attention members give to user interface design. Instead of the graphical tools being an afterthought to the text-based tools, as they seem to be in the new Debian graphical installer, for instance, Autopackage has designed both together. If anything, the graphical tools have been designed with even more care than the text-based ones.
Early in the project’s history, Hearn and Lai agreed upon basic principles for designing the graphical tools, emphasizing simplicity, aesthetics, and keeping users informed. Consistently, the results are tools that could serve as examples for the GNOME Human User Interface Guidelines that Lai claims inspired him. Unlike many developers venturing into design, the Autopackage team is not afraid of white space, and avoids cramming rows and columns of text closely together. Jargon is kept to a minimum — for example, the interface never mentions dependencies, repositories, or the root password. Instead, when these terms might be used, it presents explanations of what is happening or required. Most of the time, users are kept reasonably informed of what is happening, although the software gives full explanations only in the text-based commands. Nor do users have to interact with the tools, except to respond to simple questions.
Another guideline is for developers: To keep the interface flexible enough that new features can be added without a major redesign.
Mostly, though, the emphasis has been on users. “This stance on user interaction has been a bit controversial,” Hearn says, “But, as Havoc Pennington recently blogged, design goals always eliminate some things in favour of others.” By remaining focused on the user experience, Autopackage has also enhanced its own goals.
Autopackage documentation
Autopackage has paid attention to documentation from the start. The project site includes everything from a guide for first-time users of packages and a guide to developer tools to a step-by-step tutorial on building packages to a complete developer’s guide. All are simply and concisely worded; the package tutorial, for instance, is clear enough that even a fairly inexperienced GNU/Linux user could follow it successfully. In most of the documentation, most steps are illustrated with screen shots from the desktop or the shell.
Lai, who oversees Autopackage documentation, believes in the importance of this effort. “Having good user documentation,” says Lai, “will help users get work done instead of hanging around on an IRC channel or on Google looking for a vague answer on an obscure forum. Having good developer documentation will stimulate contributions.” It’s a philosophy that would benefit many other projects.
The outlook for Autopackage
With version 1.0 released only last spring, Autopackage still has room for improvement. Currently, the software supports only x86 architectures. It supports upgrades only through the clumsy expedient of removing the old package then installing the new one. It cannot read the databases of other package management systems, which could potentially increase the speed of its search for dependencies.
It’s also not clear whether Autopackage’s current interface will be adequate when the system is widely used. Neither Hearn nor Lai see this problem as urgent, since Autopackage is intended to manage only desktop applications, not every package on the system. However, Lai is already thinking of organizing packages into categories, just in case. He is considering organizing packages by function, such as user applications and icon packs, rather than software type, such as word processors.
In addition, the project has a long-term vision that it is working towards. Features that play a role in this vision include direct installation of software from a Web page and removal of packages by dragging their icons to the Trash. Project members are also considering packages that are complete in themselves, but gain functionality when other dependencies are involved. Yet another consideration is the security risk that such features would create.
Meanwhile, Autopackage is off to strong start. Perhaps it will not be the system to transform GNU/Linux package management. It faces competition from both long-established older systems and newer ones just as ambitious as it is. Yet, if nothing else, the project’s original ideas about the structure of package management should start some long overdue discussion. And I suspect that, no matter how package management evolves, at the very least, Autopackage’s emphasis on usability and documentation will become a major contribution.
