If you've used Linux for more than ten minutes, you've almost certainly come across the nightmare that is package management. You know what I mean - dependancy hell has become legendary and it's no exagguration to say that one of the most offputting aspects of Linux for a new user is the lack of InstallShield type 3 click installs. This article looks at how we ended up in the quagmire of RPM and dependancy hell, and then moves on to talk about a possible solution in the form of
autopackage. It takes a high level overview of how autopackage works and what it's capable of. If you want more technical details, check out the website. Finally, this article assumes only that you're interested, not that you have any Linux experience.
First off, I'm not going to assume you've used Linux before, so I'll start with a few definitions:
- RPM: The Redhat package manager. Despite the name, it's
used by many Linux distributions and is probably the most popular
package manager statistically speaking today. Unfortunately,
RPM has many faults, perhaps the most important being that it was
never designed for internet based distribution of software for Linux
in general. What this means is that it's optimized for transferring
large amounts of software to an OS from a CD or Redhat update
site. Because of the lack of flexibility in the RPM file format,
various distros have tweaked it and so forked the format - if you
want to install an RPM you'd better be sure it's designed for your
distro. Only the very simplest of packages can be realistically
distributed in this way by third parties. To make matters worse
RedHat often gratuitously break backwards compatability.
- Dependancy hell: Due to the non commercial nature of
Linux, packages often have lots of dependancies. These are other
packages that must be installed before that package can be
installed, we say one depends on the other. All operating
systems have dependancies, but Linux software has far more than
most. Dependancy hell arises when you want to install a package, but
your system doesn't have the required dependancies present. Raw RPM
cannot fix this itself - you must manually track down and install
those packages. Just pray that there are no sub-dependancies as
well!
- APT: Advanced Packaging Tools, originally built for
Debian and later ported to RPM, apt can automatically resolve
dependancies. Installing software with apt is easy, even easier than
on Windows - you just type in the name of the software you want, for
instance with
apt-get install gimp. Unfortunately, apt
requires centralised repositories to be maintained for every distro
(and often, every subversion), and as such often the software you
want is simply not available in the repositories, or it is present,
but its dependancies are not. Although Debian has many thousands of
packages in its repositories, the manpower required to keep them all
up to date means the latest versions of the packages are often only
available in Debian some time after they have been
released. emerge is a similar idea, but tied to Gentoo.
- RPM Hell: another type of unpleasantness that is caused
by the type of package managers in use today on Linux. If the
software you want to install isn't available as a package for your
distro then all is not lost, you can just compile it from the source
(which unless you use a ports based distro a la Gentoo has its own
set of problems). Unfortunately, you just entered the twilight zone:
RPM (and also the debian system) assume that you use them to install
everything on your computer. Because often packages are not
available of course this doesn't happen, but then RPM is not aware
of the presence of those packages and will refuse to install other
packages that depend on them without manual overrides. Hacks around
this problem exist (see checkinstall) but they only partially solve
the problem
Having witnessed several of my friends try Linux only to give up in
disgust after spending several hours attempting to do something as
trivial as upgrade Mozilla, I resolved to do something about the
problem. So, what issues do we face, and how to other operating
systems fix these issues?
The first one is that RPM doesn't posseses enough flexibility to
deal with the myriad little differences between distributions. An RPM
is basically made up of a list of files and a set of pre and post
install scripts. The list of files is always relative to root, so if
your distro does not use the exact same filing system layout as the
one it was built for, the RPM will not install correctly. Another
example of distro differences would be the "install-info" script,
which is responsible for integrating TeXinfo manuals into the system:
Debian has its own version which is incompatible with the Free
Software Foundation version used in most other forms of Linux.
Table of contents
- "Autopackage, Part I"
- "Autopackage, Part II"
- "Autopackage, Part III"
