What are the pros/cons of deb vs. rpm?

Question

For whatever reasons, I've always used RPM based distros (Fedora, Centos and currently openSUSE). I have often heard it stated that deb is better than rpm, but when asked why, have never been able to get a coherent answer (usually get some zealous ranting and copious amounts of spittle instead).

I understand there may be some historical reasons, but for modern distros using the two different packaging methods, can anybody give the technical (or other) merits of one vs. the other?

Answer 1

Main difference for a package maintainer (I think that would be 'developer' in Debian lingo) is the way package meta-data and accompanying scripts come together.

In the RPM world, all your packages (the RPM's you maintain) are located in something like ~/rpmbuild. Underneath, there is the SPEC directory for you spec-files, a SOURCES directory for source tarballs, RPMS and SRPMS directories to put newly created RPMs and SRPMs into and some other things that are not relevant now.

Everything that has to do with how the RPM will be created, is in the spec-file: what patches will be applied, possible pre and post-scripts, meta-data, changelog, everything. All source tarballs and all patches of all your packages are in SOURCES.

Now, personally, I like the fact that everything goes into the spec-file, and that the spec-file is a separate entity from the source tarball, but I'm not overly enthusiastic about having all sources in SOURCES. Imho, SOURCES gets cluttered pretty quick and you tend to loose track of what is in there. However, opinions differ.

For RPM's it is important to use the exact same tarball as the one the upstream project releases, up to the timestamp. Generally, there are no exceptions to this rule. Debian packages also require the same tarball as upstream, though Debian policy requires some tarballs to be repackaged (thanks Umang).

Debian packages take a different approach. (Forgive any mistakes here: I am a lot less experienced with deb's that I am with RPM's.) Debian packages' development files are contained in a directory per package.

What I (think to) like about this approach is the fact that everything is contained in a single directory.

In the Debian world, it is a bit more accepted to carry patches in a package that are not (yet) upstream. In the RPM world (at least among the Red Hat derivates) this is frowned upon.

Also, Debian has a vast amount of scripts that are able to automate a huge portion of creating a package. For example, creating a - simple - package of a setuptool'ed Python program, is as simple as creating a couple of meta-data files and running debuild. That said, the spec-file for such package in RPM format would be pretty short and in the RPM world, too, there's a lot of stuff that is automated these days.

Answer 2

A lot of people compare installing software with apt-get to rpm -i, and therefore say DEB better. This however, has nothing to do with the DEB file format. The real comparison is dpkg vs rpm and apitude/apt-* vs zypper/yum.

For a user point of view, there isn't much difference in these tools. The RPM and DEB formats are both just archive files, with some metadata attached to them. They are both as arcane, have hardcoded install paths (yuk!) and only differ in subtle details. Both dpkg -i and rpm -i have no way of figuring out how to install dependencies, except if they happen to be specified at the command line.

On top of these tools, there is a repository management in the form of apt-... or zypper/yum. These tools download repositories, track all metadata and automate the downloading of dependencies. The final installation of each single package is handed over to the low-level tools.

For a long time, apt-get has been superior in processing the enormous metadata really fast, where yum would take ages to do it. RPM also suffered from sites like rpmfind, where you found 10+ incompatible packages for different distributions. Apt completely hid this problem for DEB packages, because all packages got installed from the same source.

In my opinion, zypper has really closed to gap with apt, and there is no reason to be ashamed of using an RPM-based distribution these days. It's just as good, if not easier to use with the openSUSE build service at hand for a huge compatible package index.

Answer 3

RPM:

• 'Standardized' (not there is no deb spec)
• Used by many different distributions (but packages from one does not necessary works on another)
• IIRC allows dependency on files not only packages

DEB:

• Growing popularity
• Allows recommendations and suggestions (possibly newer RPM allows it as well)

Probably the more important question is the package manager (dpkg vs. yum vs. aptitude etc.) then package format (as both are comparable).

Answer 4

From a system administrator's point of view, I've found a few minor differences, mainly in the dpkg/rpm tool set rather than the package format.

• dpkg-divert makes it possible to have your own file displace the one coming from a package. It can be a lifesaver when you have a program that looks for a file in /usr or /lib and won't take /usr/local for an answer. The idea has been proposed, but as far as I can tell not adopted, in rpm.

• When I last administered rpm-based systems (which admittedly was years ago, maybe the situation has improved), rpm would always overwrite modified configuration files and move my customizations into *.rpmsave (IIRC). This has made my system unbootable at least once. Dpkg asks me what to do, with keeping my customizations as the default.

• An rpm binary package can declare dependencies on files rather than packages, which allows for finer control than a deb package.

• You can't install a version N rpm package on a system with version N-1 of the rpm tools. That might apply to dpkg too, except the format doesn't change as often.

• The dpkg database consists of text files. The rpm database is binary. This makes the dpkg database easy to investigate and repair. On the other hand, as long as nothing goes wrong, rpm can be a lot faster (installing a deb requires reading thousands of small files).

• A deb package uses standard formats (ar, tar, gzip) so you can inspect, and in a pinch tweak) deb packages easily. Rpm packages aren't nearly as friendly.

Answer 5

One thing I like about RPMs is the (recent?) addition of delta RPMs. This allows for easier updating, reducing bandwidth required.

DEBs are standard ar files (with more standard archives inside), RPMs are "proprietary" binary files. I personally think the former is more convenient.

Just two things I can think off the top of my head. Both are very comparable. Both have excellent tools for packaging. I don't think there are so many merits for one over the other or vice versa.

Answer 6

Debian packages can include an installed size, but I don't believe RPMs have an equivalent field. It can be computed based on files included in the package, but also can't be relied upon because of actions that can be taken in the pre/post install scripts.

Here is a pretty good reference for comparison of some specific features that are available for each specific packaging format: http://debian-br.sourceforge.net/txt/alien.html

Answer 7

The openSUSE Build Service (OBS) and zypper are a couple of the reasons I prefer RPM over deb from a packager and user point of view. Zypper has come a long way and is pretty dang fast. OBS, although it can handle debs, is really nice when it comes to packaging rpms for various platforms such as openSUSE, SLE, RHEL, centos, fedora, mandriva, etc.

Answer 8

There is also the "philosophical" difference where in Debian packages you can ask questions and by this, block the installation process. The bad side of this is that some packages will block your upgrades until you reply. The good side of this is, also as a philosophical difference, on Debian based systems, when a package is installed, it is configured (not always as you'd like) and running. Not on Redhat based systems where you need to create/copy from /usr/share/doc/* a default/template configuration file.

Answer 9

For Debian Packages there is a large set of helper scripts, a consistent policy manual and at least one way of doing almost everything. Dependencies are handled very well and can be defined in very good granularity. Re-building packages is very easy with debian packages and well supported by the tools available.

Answer 10

Historically, my impression has always been that the Debian archive was the *.deb format's biggest strength. Since the advent of yum, that's less true, if it's true at all.

Answer 11

I think the bias comes not from the package format, but from the inconsistencies that used to exist in RedHat's repositories.

Back when RedHat was a distribution (before the days of RHEL, Fedora, and Fedora Core), people would sometimes find themselves in "RPM Hell" or "dependency Hell". This occurred when a repository would end up with a package that had a dependencies (several layers deep, usually) which were mutually exclusive. Or it would arise when two different packages had two mutually exclusive dependencies. This was a problem with the state of the repository, not with the package format. The "RPM Hell" left a distaste for RPM systems among some population of Linux users who had gotten burned by the problem.

Answer 12

Go search Google for

1. rpm duplicate packages
2. dpkg duplicate packages

Read the pages that come back. Very telling that you can have a messed up RPM database with duplicate packages in it while no such case happens with dpkg.