So does Linux have the right idea? Yes, it does. Operating systems are just that - systems, systems that are made up of multiple components. In the absence of centralised control and the use of parallel development, properly managing dependancies and system differences is a must. The problem is that we don't do it very well. So how can we improve?
I think the answer lies in autopackage, a project I started work on over 6 months ago in response to these issues. It uses a variety of ideas and approaches to solve the problems posed by Linux package management.
- Distribution neutral: unlike many package managers, autopackage
was not developed by a distribution project. As such, it is
completely distribution neutral both in technical design and
political stance. You can build an autopackage once, and it will (in
theory :) install on any distro, assuming it's not totally off this
planet.
- Designed for flexibility: In a similar vein to
InstallShield a .package file is script based rather than table
based. The install scripts, backed up by a large number of provided
library funtions, are easily capable of dealing with the multitude
of differences between distributions.
- Net based: RPM was designed to manage everything a distro comes
with, from the kernel to the Solitaire games. In contrast,
autopackage is designed for net based distribution of software. It's
not designed to install new kernels, or to be used exclusively by a
distro (maybe one day it would be capable of this too, but it's not
a design priority). As a part of the project we will be constructing
the autopackage network, a network of resolution servers that
work like DNS to convert root names (see below) into URLs for where
the packages can be downloaded. By turning our back on the idea of
apt-style massively centralised repositories, we hope to allow the
network to scale. If a programmer creates a piece of software, they
don't have to wait for somebody from the network to create a package
and upload it for them, they can create it themselves and then
register their own node of the network from which they can plug in
any packages they may create
- Global names: from the start, autopackage was designed to allow
packages to have multiple names. All packages must have a root name,
to which other names can map to. A root name looks something like
this: "@gnome.org/gedit/2.2". As you can see, rather than creating a
new naming authority, it leverages off the DNS system. As most
projects these days have a website, they can easily be assigned a
root name. Other, more human friendly names include short names,
which are rpm style (for instance "gimp", "gnome2" or "xchat-text"),
and display names, which describe in the users native language
briefly what the application is, ie "Evolution Mail
Client".
- Database independant dependancy management: the approach
autopackage takes to dependancies is similar to the configure
scripts we all use, in that it checks the system directly for the
presence of the dependancy, ie for libraries it will check the
systems linker cache. I won't go into the exact details of this
system, you can find out more information from the website.
- Front end independance: right now we have only a terminal front end, and very pretty it is too. As we work towards 0.3, we'll be developing a graphical front end based on GTK. We'll also be adding a front end that records your choices and can then play them back, allowing seamless automation of installs. By insulating packages from the details of how they interact with the user, packages are simpler to build and we can get much better integration with the users host environment. The best is chosen automatically, so if you install the package from the command line it'll use the terminal front end, and if you install it from Nautilus or Konqueror (visual file managers) it'll use the graphical front end.
- Automatic and easy: installing a .package file is simply a matter of running it. If you've never used autopackage before, the needed files will be downloaded and setup for you. Packages have minimal bloat because of this, so far it runs to about 11kb.
So is this just fantasy, a pipe dream? Not at all thankfully, a few days ago we released 0.2 which can build, install, verify, query and uninstall packages in a distro-neutral fashion. We're a long way from having a complete solution to the problem, but let's hope that in a few years the days of RPM hell will be long forgotten.
About the Author:
I'm Mike Hearn, an 18 year old from England who has been using Linux for about a year. By day I work for what was Ministry of Defence research, and by night I hack on free software (when i'm not out with friends ;). I also help run the theoretic.com website and am a chronic daydreamer :)
- "Autopackage, Part I"
- "Autopackage, Part II"
- "Autopackage, Part III"
