openSUSE:RPM sucks
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!
rpm is not an open standard
Why rpm is not an open standard
The problem with rpm is that there is no specification. What rpm accepts is a valid package, what rpm does with it is the correct interpretation of the package. This evolves over time as changes in the package manager are implemented.
No specification of spec file and macro file syntax
The spec file syntax is not documented. While guides for specific use cases exist the full syntax specification does not exist. There is complex interaction between the spec file syntax and the syntax of the the embedded shell scripts. These interactions as well as the degree to which various macro constructs are expanded varies across rpm versions. An additional variant of similar but different file are the macro files that define macros that can be used in the spec files. In contrast many other packaging formats use well defined syntax - dpkg uses makefiles for the build recipes, and makefile syntax and semantics are defined in detail.
No specification of package metadata
The package metadata, and especially the package dependencies are not documented. Guides for specific use cases exist but the exact meaning of different dependencies is not defined. This means that what rpm or a solver does with your package can be only determined by experimenting with different versions of these tools, and differences in dependency handling across versions do exist. In contrast Debian has packaging policy manual which describes each field that can appear in a dpkg package and its meaning in detail.
Consequences of lack of open packaging standard
Without a standard you have to accept that what is valid package and how your package is handled can change at any time without notice. This is not a theoretical problem - breaking changes in rpm do happen.
Another problem is that for any given behavior it is not clear if it is rpm and solver feature or a bug. This in turn means that implementing any changes in the package manager is difficult and finding new developers to work on it nearly impossible.
Finally any packaging effort and any project that has packaging needs outside of the common use cases described in packaging guides requires gatekeeping by the already scarce rpm and solver developers for determining feasibility and correctness. This in turn causes overload of the developers and stifles innovation in the distribution as a result.
Overview
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 uses xz, openSUSE uses old-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.
Building Packages
- RPM specfiles use shell mangled in an unspecified way - there is no spec file syntax specification. DEB however uses Makefile-Shell syntax, which is precisely documented.
- To make an RPM package, the minimum amount of non-tarball files is one — the .spec file itself. This file contains a number of resources in an unspecified format that are interdependent so they cannot be extracted and examined separately. DEB packages commonly have 5 to 7 (control, watch, rules, etc.) which are precisely defined.
- 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)
- Soft dependencies like "Recommends" and "Suggests" are possible with RPM as well as with DEB.
- capabilities (provides) are possible with both RPM and DEB but with RPM they are effective only with some dependencies.
- RPM (with rpm ≥ 4.10, used in openSUSE 12.3/Fedora 18 and newer) supports versions like “1.0~beta2” now (which sorts in lower than 1.0). This means that hacks like “0.99_1.0.beta2” are no longer required when building with the official rpm binaries.
- Both RPM and DEB have package scripts that run at the end of whole transaction but for RPM they run only on install, not uninstall.
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 and DEB allow to install multiple arches of the same package (same name and version). This is rarely done with rpm in practice however because rpm -U leads to “unexpected” results (it upgrades, obviously, and upgrade means removal of all previous versions). This is handled gracefully by dpkg since multiarch support was added.
- 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 because rpm does not track the state that is purged by dpkg. - dpkg tracks the scriptlet execution status during package install/removal so that interrupted transactions can be resumed. Unfortunately, this status is intermixed with original package metadata in one huge text file which is slow to parse, unreliable, and cannot be recovered when corrupted because it contains data above what is shipped in the packages.
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”). This split allows specifying multiple URLs from the same repository effectively but is somewhat unwieldy.