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

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 aptitude/apt-* vs zypper/yum.

From a user's point of view, there isn't much of a difference in these tools. The RPM and DEB formats are both just archive files, with some metadata attached to them. They are both equally arcane, have hardcoded install paths (yuck!) 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 on the command line.

On top of these tools, there is 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 amount of metadata really fast while yum would take ages to do it. RPM also suffered from sites like rpmfind where you would find 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 the gap to 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.

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 RPMs you maintain) are located in something like ~/rpmbuild. Underneath, there is the SPEC directory for your 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 lose track of what is in there. However, opinions differ.

For RPMs 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 derivatives) this is frowned upon. See "FedoraProject: Staying close to upstream projects".

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.

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.