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

In [[an earlier entry FedoraVsUbuntuDesktopView]] 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 DebianAndRPMSourcePackages]], 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 DebianSourcePackageProblems]] and [[here
DebianSourcePackageProblemsII]] on the hassles of working with Debian
sources, [[here DebianVsRPMSourcePackages]] on the different tradeoffs
of Debian and RPM source packages, and [[here UpstreamPackagingProblem]]
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 Lib64VersusLib32]], 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
QuestionsConsequence]] through [[ambushing sysadmins with landmines
DebianPackageDisfavour]] 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.)