Another Look at Linux Packaging Systems

The sad shape of apt-rpm, especially in combination with rpm5, has caused us to look at alternatives. Our decision to go with rpm and apt-get was made when we started 8 years ago – since then, a number of new things have come up and a lot of things could have changed.

Looking at the basic package managers out there, a lot of things have remained the same – while rpm and dpkg both made some progress, they’re basically what they used to be — both work, both have their own set of problems, but we do still believe our decision to go with rpm was the right one: rpm spec files are much easier to understand especially for non-programmers, and for experienced users, they take less time to write.

The problems people commonly talk about when saying rpm sucks are often not related to rpm — e.g. the “dependency mess” is caused by people trying to mix packages from Ark, Fedora, SuSE, Mandriva, Yoper, … – all of which are different core systems, using different package naming conventions, and slightly different filesystem layouts.
dpkg would have the exact same problem – if someone actually used it to build a fresh distribution with dpkg that didn’t share Debian’s core system (or something close to it), you’d run into the exact same thing as soon as people tried to mix packages from that new distribution with one of the traditional Debian derivates.

In addition to the big 2, there have been some newer entries into base package managers – most notably Pacman and PiSi.
Both of these are quite nice, and would be serious contenders if we were starting a new distribution from scratch – but neither of them offers enough of an incentive to make us want to put in the effort of converting our existing packages to something new. They also come with some drawbacks. While e.g. PiSi’s XML package descriptor solves a few problems, it is also harder to read or setup for a newbie, and we’re still trying to make creating packages newbie friendly (of course, a graphical package generator wouldn’t have too hard a time writing XML). Pacman’s idea of subpackages differs quite a bit from rpm’s idea (Pacman has different DESTDIRs for different subpackages, while rpm goes by file lists), and the way Ark packages tend to be split, creating subpackages using pacman would involve moving around files after installation – making it a bit more cumbersome than doing things rpm’s way. From a quick look, pacman also doesn’t seem to have an equivalent of rpm’s “Provides:” tag.

In terms of package managers that run on top of the base package manager, lots of things have come up, not all of which existed back in 2001 — smart, yum, zypper, urpmi and poldek can do the job of apt-rpm.

smart, yum and urpmi are written in scripting languages (Python for smart and yum, perl for urpmi) – which has a drawback for something important for system recovery: If you break the interpreter (e.g. if the user does something stupid like trying to manually compile a shiny new Python 3.x to replace the “obsolete” 2.6 installation that came with the OS), the package manager won’t help you recover.

Of course, people might argue that you can break libc.so.6 or libstdc++.so.6 too, but if you do that, chances are your system is messed up so badly that you can’t fix it without booting from some other device anyway.

This is not a major showstopper (you can still boot from a live CD or install CD and run the package manager from there), but it is a reason for us to prefer a package manager written in C++ or C.

This leaves zypper, poldek and apt-rpm as our favorites — looking at the code of each, we’ve decided that, if further testing doesn’t prove us wrong, our next release will be using zypper.

It is readable code, porting it to rpm 5.x took us only a few hours, and the upstream developers were very responsive to our questions.

One potential source of problems with zypper is the order in which it does some things ‚Äì e.g. when installing a package with many dependencies, zypper downloads a package, installs it with ‚Äìnodeps, downloads the next package, installs it with ‚Äìnodeps and so on [while apt-rpm downloads all packages first, then installs them in one go, avoiding the need for –nodeps].

This slightly increases the chance of corrupted packages when aborting a package installation.

This should be fixable with a bit of work though – and isn’t as big an issue as it may sound, another call to zypper will fix the corruption, and aborting package installations isn’t exactly recommended everyday use.