Why the RPM source and binary package format is superior to Debian .debs

September 9, 2013

In an earlier entry I mentioned that I felt that RPM was a better package format in practice than Debian .debs. Today it's time to take a stab at justify this. But to start with, let's talk about what this entry is not about.

In the old days Debian was superior in practice because the whole apt software suite and ecology had no real equivalent in RPM land. Those days are long gone. These days yum is as much as part of the RPM ecology as apt is for the Debian package one, and in fact the rpm command has been demoted to the same general footnote status that dpkg is in Debian. Having used both I feel that yum and apt are sufficiently comparable that I'm not going to quibble back and forth. So this entry is purely about the package format itself, not the surrounding tools.

There are two sides to this, source packages and binary packages. In the source package world, RPM is in the lead because of the way that it systematically organize changes to the source and does builds outside of the package's source area. I wrote about this at length here and here on the hassles of working with Debian sources, here on the different tradeoffs of Debian and RPM source packages, and here on why the Debian tradeoff is the wrong one.

For binary packages I'm going to set aside Debian's misstep with x86 multi-arch support, partly because I understand it's increasingly being fixed. In practice there are two important differences between the package formats: RPMs can and generally do depend on files while .debs depend on packages and Debian packages can ask you questions at install time while RPMs never do. The dependency issue is the lesser one. Depending on packages is brittle in the face of other people reorganizing their packages and also requires a somewhat indirect process for determining a package's dependencies when the package is built. Depending on files means that RPMs are agnostic about just what provides those files and the RPM build process can easily determine most dependencies by direct examination of packaged programs and so on.

In the abstract asking questions at install time sounds great or at least harmless. In practice it's a disaster that enables a catalog of bad practices, ranging from people papering over internal divisions through ambushing sysadmins with landmines to drastically complicating attempts to do automated and semi-automated installations and package updates. By contrast RPMs have a very hard rule, enforced by the system, that a package cannot interact with the user at install time at all. Packagers are forced to make decisions and insure that the package setup is sane, while sysadmins can script and otherwise automate RPM installs without worry.

Theoretically you can turn off all install time questions on Debian. In practice this can't be trusted because it's not the default state of affairs. Oh sure, it's probably considered a bug if a Debian package screws things up on a no-questions install, but do you want to be the first person to find that bug? If you are a sane sysadmin, the answer is 'no' (not unless you have no choice). In practice what is fully supported is what is routine and in the Debian world that's asking you questions during package installs.

(It's possible that graphical package management is changing this, but I'm not holding my breath.)

Comments on this page:

Well, there's one quite big downside of RPM format. It has no way of expressing alternative dependency: require either perl(Foo) or perl(Bar), as the package can use either of them. One is forced to change other packages to define new virtual package.

I will probably sound pedantic here, but RPM packages never depend on files, they just have a bunch of virtual provides and dependencies added by the package generation tools (at least the filenames of all executables and the sonames of all libraries). This can be disabled or overridden at build time, and this can lead to annoying packaging bugs. I remember a broken dropbox package which used to provide libsomething-or-other.so and which got pulled by yum instead of the "real" library package, for instance.

I generally agree RPM is a good packaging format, but I guess my point is that it has a lot of magic going on behind the scenes which can lead to surprising side-effects.

-- Arnaud Gomes

By Zazzle at 2013-09-10 14:23:32:

Realistically though, both .debs and .rpms have a long way to go. Although, they are both making progress.

The Debian questions during install can be annoying, but they are scriptable. The process is not great, but it can be done. Example:[1]

Packages created by rpmbuild often do not include version numbers (for which the blame falls on my 3rd party vendors), which makes updates a remove and install, instead of a clean update.

References: [1] http://serverfault.com/questions/407317/passing-default-answers-to-apt-get-package-install-questions

P.S. I sometimes disagree with you, but I always enjoy reading.

By Ashay at 2013-09-10 15:05:41:

Apart from asking questions at install time, debian/ubuntu package also tend to have the annoying habit of starting services immediately after install.

Which sysadmin wants things like puppet or mysql-server to start without any customization?

And, the people behind yum are doing far more interesting things, like making yum plugins like yum presto.

Also, rpm/yum stores the package install time-stamp in the rpm database, while dpkg/apt just stores it in a text log, which may be eventually erased.

Thanks for the good summary. I agree with you though I'm biased. RE: future changes in RPM/YUM I thought this was a good thread: https://lists.fedoraproject.org/pipermail/devel/2013-May/thread.html#183167

Written on 09 September 2013.
« A slow realization: many of my dotfiles don't need to be dotfiles
Understanding why CSRF protection really needs cookies »

Page tools: View Source, View Normal, Add Comment.
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Mon Sep 9 23:57:34 2013
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.