tagline: From openSUSE
This page will give you, as an openSUSE ambassador, arguments in a discussion about RPM vs other package formats.
TODO: it mostly talks about RPM vs DEB, there should be more!
Some old stereotypes about RPM not resolving dependencies correctly is the basis for critique against rpm, and distributions making use of it, among them openSUSE. These people blame the package format, or the rpm program, while in fact, the issues were with tools developed around the core.
One of the most common errors is to compare rpm to apt-get, when the comparison should have instead involved dpkg.
A few years ago, rpm depsolvers, as they are technically called, used to be admittedly weaker to the well known apt from Debian. People with less knowledge of the interactions of packaging then made the corollary assumption that .debs were superior to RPM. In fact, apt was ported to handle rpm packages as a stop-gap for existing rpm tools.
Nowadays, the issue of rpm dependency resolution has been solved. Both zypper, mostly developed by SUSE, as well as yum, developed mostly for RedHat/Fedora are both mature and reliable depsolvers.
RPM vs DEB (format)
- RPM is an LSB standard. DEB is not.
- RPM supports Xz compression. deb also supports xz compression and dpkg-buildpackage defaults to it.
- In practice, the Debian and offspring projects still use .gz almost exclusively, despite the deb format being said to support gzip, bzip2, xz, and LZMA (WP). This makes for larger packages, slower installs and slower updates online.
- Fedora is already using Xz, openSUSE is currently still on its way to transition off LZMA.
- RPM consists of internal metadata plus a single cpio archive holding the files. DEB uses a Unix ar(1) archive, which contains two tarballs in turn.
- rpm specfiles use plain shell, save for the extra escaping of % to %%. deb however uses Makefile-Shell syntax, which means a lot more pitfalls.
- To make an RPM package, the minimum amount of non-tarball files is one — the .spec file itself. DEB packages commonly have 5 to 7 (control, watch, rules, etc.).
- RPM used standard ("quilt-type") patches for years. DEB predominantly uses quilt as of 2014.
- DEB disallows use of “_” in package names and versions (leading to weird rename orgies, e.g. pam_mount -> libpam-mount)
- Starting with rpm 4.7 (perhaps earlier? or is it an openSUSE patch?) soft dependencies like "Recommends" and "Suggests" are possible with RPM as well DEB.
- rpm.org maintainers are slow in integrating the tilde patch that makes versions like “1.0~beta2” possible (which sorts in lower than 1.0). Meanwhile, hacks like “0.99_1.0.beta2” are required when building with the official rpm binaries.
rpm vs dpkg (the tools)
- http://jengelh.medozas.de/linux/adm_pack.php — please fill in any missing parts
- RPM as an all-in-one tool to do package inquiry; on the Debian side there is dpkg and dpkg-query.
- RPM allows to install multiple versions of the same package (same name).
- RPM allows to install multiple arches of the same package (same name and version). This is rarely done in practice however because rpm -U leads to “unexpected” results (it upgrades, obviously, and upgrade means removal of all previous versions).
- RPM has deltifying technologies of various levels: patch.rpm and delta.rpm. No such techniques seem to be used in the DEB world.
- There is no extra “purge” step (`
apt-get purge`) required in RPM.
Zypper vs APT
- libzypp has a satsolver. apt only a heuristic searcher.
- zypper has vendor locks. (No more "package takeover" from 3rd-party repositories on updates.)
- Specifying files as arguments to “zypper install” is possible.
- Command-line apt package search using apt-cache is a little awkward — it returns results that do not have the search string in it at all (perhaps because it searches in the longer package descriptions too). In most cases, one wants to pipe it into grep to yield `
zypper search` semantics.
- Zypper uses plain URLs. APT uses a scheme that just splits in the middle (“deb http://mirror/debian lenny/main”).