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?

12 Answers
12

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.

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.

To correct you on Debian packaging, the debian directory exists in the directory into which the upstream source was extracted into, and Debian does value the concept of a pristine upstream source tarball very much. When a source package is built, there are three (two for native packages) files that together are called the source package: the upstream tarball (preferably pristine, Debian policy requires some projects to be repackaged), a tarball of the debian dir for the new 3.0 format, (a diff for the old 1.0 format) and a .dsc.
–
UmangAug 18 '10 at 16:17

8

The debian directory doesn't go into the upstream tarball, it remains in the .diff.gz or the .debian.tar.gz files of the source package, although the debian directory is inside the source tree when the source package is extracted. BTW: when policy doesn't require repackaging, the tarball's MD5 has to match with the upstream tarball's. Also, to clarify, patches made my the maintainer to the upstream source are stored in the debian directory (source format 3.0) and in the .diff.gz (format 1.0).
–
UmangAug 18 '10 at 16:18

Umang, thanks for your correction. I will remove the part about altering upstream's tarball to make sure no-one gets the wrong idea.
–
wzzrdAug 18 '10 at 16:26

2

Looks fine now, except you've still got a "For RPM's it is important to use the exact same tarball as the one the upstream project releases, up to the timestamp." Because of my total lack of experience with RPMs, I don't know whether the difference in policy is huge, but like I said, a Debian Developer will insist on it being exact to the timestamp unless the upstream tarball violates Debian policy and needs to be repackaged.
–
UmangAug 18 '10 at 16:33

7

@wzzrd, it's actually easy to have your source files put together in a per-package directory, by defining %_specdir and %_sourcedir in your ~/.rpmmacros file.
–
mattdmDec 3 '10 at 3:44

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

In my opinion, I've despised RPM's for the exact reason you mentioned: "RPM also suffered from sites like rpmfind where you would find 10+ incompatible packages for different distributions." Also I find it excessively difficult to find an RPM for software I need. While for DEB: "Apt completely hid this problem for DEB packages because all packages got installed from the same source." which are really easy to find and use. Also, DEB always seems to find and install dependencies better while RPM's seemed to always let me hanging... my opinion after 15 years of using both!
–
JeachFeb 28 '13 at 21:36

@Jeach: yes. the difference is not in the file format (very similar), or tools nowadays, but rather in past opinions and how people manage the environment surrounding both formats. I'm mostly using openSUSE and Debian nowadays
–
vdboorFeb 11 '14 at 13:42

1

I believe this answer addresses the question from a consumer point of view, unlike @wzzrd's which is entirely developer/packager centered. Also, very clear about the level separation.
–
gnpFeb 11 '14 at 21:28

1

From a user's perspective, this is the best answer. And I would add that using PPAs is much more simple than adding a new yum repo.
–
Lucas MalorSep 12 '14 at 13:34

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

It looks like these days it saves the new configuration file with *.rpmnew instead of clobbering your modified one - at least on openSUSE.
–
EvanAug 21 '10 at 0:56

Both are done, so you get a scattering of rpmsave and rpmnew files.
–
Burhan AliMar 16 '12 at 8:31

3

You're incorrect about RPMs do not use standard formats. RPMS use CPIO for the data section - which is a standard archive format. The other sections are mostly headers. You can use the tool rpm2cpio to extract only the data section of the RPM and extract the files contained within the rpm. For example: rpm2cpio foobar.rpm | cpio -idmv
–
TuxdudeOct 8 '12 at 21:13

"dpkg vs yum" is the wrong comparison as the former is a package manager but the latter is not (just as apt/aptitude are repository level managers rather than just "package").
–
Michael ShigorinFeb 15 at 20:15

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.

As several responders said, it is not so much that a certain package format is clearly superior. Technically, they may be more or less comparable. From my perspective a lot of the differences, and why people prefer one over the other, have to do with:

The philosophy of the original package design and the target audience

The community size, and by extension, the quality and richness of the repositories

Philosophy:

In the Ubuntu/Debian/Mint/... world, users expect the installed package to "just work" once it is installed. This means that during installation, packages are expected to take care of everything needed to actually make them run well, including but not limited to:

setting up needed or optional cron jobs

setting up alternatives/aliases

setting up startup/shutdown scripts

including all needed configuration files with defaults that make sense

keeping old versions of libraries and adding the right versioned symlinks to libraries (.so's) for backward compatibility

clean support for multi-arch (32 and 64 bit) binaries on same machine
and so on.

In the rpm world -- admittedly this was the situation several years back, and it may have improved since then -- I found myself having to run additional steps (e.g. chkconfig, enabling cron jobs) to actually make packages really work. This may be ok for sysadmins or people who are knowledgeable about Unix, but it makes newbie experiences suffer. Note that it is not that the RPM package format itself prevents this from happening, it is just that many packages are de-facto not "fully done" from the perspective of a newbie.

Community size, participation, and richness of repositories:

Since the ubuntu/debian/mint/... community is larger, more people are involved in packaging and testing software. I found the richness and quality of the repositories to be superior. In ubuntu I rarely, if at all, need to download source and build from it. When I switched from Red Hat to Ubuntu at home, the typical RHEL repo had ~3000 packages in it, while at the same time, ubuntu+universe+multiverse all available directly from any Canonical mirror, had ~30,000 packages (roughly 10x). Most of the packages I was looking for in RPM format, were not readily accessible via simple search and click in the package manager. They required switching to alternate repositories, search the rpmfind service web site etc. This, in most cases, rather than solve the problem, broke my installation by failing to restrict what dependencies can or cannot be upgraded correctly. I hit the "dependency hell" phenomenon, as described above by Shawn J. Goff.

In contrast in Ubuntu/Debian I found that I almost never need to build from source. Also because of:

The Ubuntu fast (6 month) release cycle

The existence of fully compatible PPAs which work out of the box

The single source repositories (all hosted by Canonical) no need to search for alternative/complementary repos

Seamless user experience from click to run

I never had to compromise on older versions of packages I cared about, even when they were not maintained by official (Canonical) developers. I never had to leave my favorite friendly GUI package manager to perform a convenient search by keyword, to find and install any package I wanted. Also, a few times I installed debian (non Canonical) packages on Ubuntu and they worked just fine, despite this compatibility not being officially guaranteed.

Note that this is not intended to start a flame war, it is just sharing my experience having used both worlds in parallel for several years (work vs home).

It's rather about "redhat vs canonical" (with canonical reaping what debian has been doing for two decades) and not about "rpm vs deb" -- I tell that as an ALT Linux Team member.
–
Michael ShigorinFeb 15 at 19:58

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.

Calling RPMs "proprietary" is a bit strong. There are some additional headers and such, but the core of an RPM is a gzip-compressed cpio archive. There's a tool that comes with RPM called rpm2cpio that lets you extract this core so you can play with it just like you can with a .deb file.
–
Warren YoungAug 18 '10 at 14:08

3

Rubbish. RPM's are not proprietary binary files. They used to be built around cpio (which is old, yes, but not proprietary), while newer versions of RPM use xz, which is available as open source, too.
–
wzzrdAug 18 '10 at 14:15

Right, I quoted it, because of course it's not truly proprietary and that's exactly what I mean: additional headers, etc. so it's not quite a straight ar file like a deb. Not a huge deal, just a minor thing.
–
johanssonAug 18 '10 at 18:01

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.

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.htm (according to the web server, that document is fairly old: Last-Modified: Sun, 15 Oct 2000 so this might not be the best reference.)

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.