What's wrong with depsolvers like apt? Now apt and friends are fine tools for sure, but they do not solve the developers problem of how to get the latest version of their program to their users now, and not in six months time when it finally gets packaged and integrated into the repositories of all the distributions out there. The apt model of centralised repositories is the polar opposite of the decentralised model of software distribution as used by Windows, MacOS X and BeOS. What makes sense for the packages comprising the operating system itself doesn't make much sense for third party applications. Even if it was possible to provide an apt repository in which everything was packaged and everything was up to date, the usability problems would be crippling. Synaptic offers unmanageable lists of choice and solutions such as gnome-app-install simply lessen the problem but do not eliminate it. Even search-oriented rather than list-oriented interfaces have problems: no matter how smart your searching is, you'll never beat Google. Other problems, which you can read about in the FAQ, slam the nails into the coffin of this model.
Moving to a decentralised model for distributing applications raises fundamental questions about the structure and design of Linux. It's no longer enough to guarantee source code portability - instead, binary portability must be provided too. It's no longer enough to check for optional libraries in a configure script and compile the code to use them out when missing, instead the libraries must be linked to at runtime and the fallback path used if the library is missing. It's no longer enough to have to guess what is on your users systems: instead a large and solid platform is required on which developers can build.
During the development of autopackage, we have considered and addressed many of these problems. Binary portability problems have been tackled with an easy to use GCC wrapper, called apbuild. The POSIX dlopen interface is awkward to work with, so relaytool was written to make weak linkage a snap. It makes it easy to fall back to the old GTK+ file chooser if the new one is not available, or disable spell checking if gtkspell isn't installed. Finally binreloc is a toolkit for making programs installable to any prefix at runtime: this allows users without root to install software to their home directory, and administrators can install programs to network mounts and additional hard disks without needing union mounts or LVM. It's a rule that autopackages must be relocatable.
Looking towards the future
There are lots of ideas and plans for what happens now. Probably the most important is native package manager integration. Right now, autopackages integrate well with a variety of desktop environments. However, it doesn't integrate much with the underlying package management technology. In future, it will do so.
That means registering with the RPM database when a package is installed so you can list its files and metadata, so it can fulfil dependencies for other RPMs and so it's possible to smoothly upgrade a package from RPM to an autopackage or vice-versa. It means using apt-get, yum or emerge to resolve dependencies as well as autopackages own built-in dep resolution. Finally, it means a way to put autopackages inside apt repositories to aid deployment on managed networks.
Dependency hell is a difficult problem to solve, as you may have guessed by the fact that it still plagues Linux as late as 2005. Nothing in the design of autopackage stops a developer depending on extremely new, rare or unstable libraries - the primary cause. While autopackages check the system directly for what they need (so avoiding the problem of inconsistent metadata and package managers that don't recognise source installs) if you actually don't have the necessary code then the install will fail. To solve this, it is essential to provide developers with a broad base of functionality that can be depended upon with only one expressed dependency: a base set or platform.
The user interface provided by both autopackage and traditional
package managers isn't best of breed. What should be seamless and
transparent is not: the user is still expected to understand the
distinction between a program and a package, and has to comprehend
the purpose of installation. This means users need to think about
non-obvious questions "Do I keep the package I downloaded around?
Do I still need it after installing it? Can I send it to other
people?". Drag and drop is not supported. Support for upgrades and
uninstallation is crude and not integrated with the desktop. Many
of these issues affect other platforms like Windows and MacOS X
too, but we should aim high. Solving this means integrating
package management with the desktop so applications become
first-class objects that the user can manipulate just like
documents. The concept of "installation" should fade away and
eventually disappear thanks to seamless desktop integration not
only with autopackage but with all package managers.
Meeting these goals head on will take time, effort and dedication. At the end, we should have a better system in every way: more powerful for developers, more flexible for administrators and simpler for end users. We can raise the bar. We should raise the bar. Let's get started.
- "Autopackage, Page 1/2"
- "Autopackage, Page 2/2"
