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.

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 or 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.


About arklinux

Founder of Ark Linux
This entry was posted in Ark Linux, Development, Future plans and tagged , , , , , , , , , , . Bookmark the permalink.

15 Responses to Another look at Linux packaging systems

  1. Viper550 says:

    Little note, pacman [b]does[/b] have depends. He just wasn’t looking hard enough.

    • arklinux says:

      Thanks, I’ve updated the article to not spread wrong information. I did overlook the provides= statement initially.

  2. proyvind says:

    you can compile smart as c++ code though, the unity linux project from what I understand is doing just this for creating a minimal rescue cd without python dependency.

    With rpm in ark statically linking everything etc. already, I would think that doing “kinda the same” with python wouldn’t be so much out of the question for you guys? :o)

  3. Pingback: Duncan Mac-Vicar P. · Ark Linux to adopt ZYpp

  4. Pingback: Ark Linux to adopt ZYpp - openSUSE Forums

  5. Carlos Goncalves says:

    “This slightly increases the chance of corrupted packages when aborting a package installation.
    This should be fixable with a bit of work though”

    Not yet implemented indeed but will take care of it in a near future. Stay tunned 😉

  6. lefty.crupps says:

    After years of bouncing around distros, I still find RPMs to be a headache, even without 3rd party repos (which are all-too-often needed because no RPM-based distros ever have the ‘right’ software).

    APT is where its at, IMHO, but I’ve never had to build packages for an apt-enabled distro that isn’t Debian based (except *buntu but i don’t care about them any more).

    I would love to see a package manager which can save snapshots of packages, version numbers, the package locations on-line, and the config files, so that a desktop Linux user can upgrade or downgrade and be able to roll back at any time.

  7. Pingback: Ark Linux paserà a zypper? « Crismon's Blog

  8. fabio says:

    what about conary package manager???

    • arklinux says:

      Conary shares the interpreted language problem of smart, yum and urpmi; it makes it worse by having the interpreted language at an even lower level.

      The files you use to create a package with it are programmer friendly, but not exactly end user friendly (imagine someone who is not a programmer, but has managed the basics of using a real OS, trying to build packages — with rpms, it’s quite possible, because an rpm spec file is basically a list of shell commands with some extra information, but Conary and friends actually make it necessary to learn the basics of a programming language [which is fine, if that’s the primary user group you’re targeting — but it’s not really suitable for something focused on making end users’ lives as easy as possible.]).

  9. Pingback: Novell News Summary - Part I: OpenSUSE Graphics, Ark-ZYpp Win, and More Open Development | Boycott Novell

  10. Pingback: Ark Linux bude mít zypper « Linux Blog

  11. Gary Greene says:

    The new version of Zypper fixes this with the ability of downloading the stuff first and then doing the installations, which eliminates the problem quite nicely.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s