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