|
HTML rendering created 2026-01-16 by Michael Kerrisk, author of The Linux Programming Interface. For details of in-depth Linux/UNIX system programming training courses that I teach, look here. Hosting by jambit GmbH. |
|
|
NAME | DESCRIPTION | SEE ALSO | COLOPHON |
|
|
|
RPM-DESIGN(7) Miscellaneous Information Manual RPM-DESIGN(7)
rpm-design - RPM design philosophy
RPM is a general purpose software manager. It has two major parts:
rpmbuild that combines upstream sources with a meta data and build
instructions in a "spec file" and additional files and patches. It
allows to bundle all this up into a source package and build the
software into a binary package. The second part - the rpm utility
- can then install, update or remove the packages after checking
for consistency.
Design goals
• General purpose software management
• Building from pristine sources
• Unattended operation
• for building packages
• for installing/updating/deleting packages
• Reproducibility of builds and installs
• Verifiability of packages and installed software
General purpose software management
RPM differs from special purpose package managers - like those
targeting a specific programming language - in trying to not make
assumptions about how software looks like or gets packaged.
Packaging software can be messy and RPM accommodates for that.
It still offers help to create a POSIX-like operation system.
Macros parameterize locations to make the build instructions more
generic and more easily transferable between distributions.
Nevertheless RPM packages are targeting a specific distribution
(and release thereof). They are typically not suited to be
installed or even built elsewhere without tweaking. RPM
acknowledges that different distributions have different goals,
resulting in different design decisions. The specifics of the
packages often reflect these.
RPM as a upstream project still tries to keep distributions from
diverging unnecessarily but is aware that these differences are
the reason distributions exist in the first place.
Rolling out (security) updates quickly
Getting updates installed quickly is one of the main design goals.
Many features and following design decisions are supporting this
goal.
Packaging dependencies separately
Libraries should be packaged separately and binaries should link
to the version provided by system packages. Static linking is
discouraged. This limits the number of packages that need updates
or re-builds in case of a vulnerability.
Unattended operation
Package installation and update is unattended and must not require
user interaction. This allows automatically installing security -
and other - updates.
Building the packages also runs unattended. This prevents user
input from changing the output but also makes rebuilding packages
- e.g. for changed dependencies - possible at large scale.
Clear update path
Each package name creates an update path where packages with the
same name and a newer version (technically Epoch-Version-Release)
are an update for the packages with lower version. Packages are
not allowed to make assumptions on what intermediate packages were
installed or not.
Bundle Sources, Changes and Build instructions together
Source packages bundle upstream sources, patches and build
instructions into one entity. If changes need to be made
everything needed is available, including a list of packages
needed to run the build.
Separate Upstream Source from Patches
Source packages are supposed to contain the unaltered upstream
sources in a way that their checksum can be checked. All changes
can be done by applying patches or running build scripts. This
makes it easy to understand what the packager did to the software.
This is important to be able to figure out where issues arise from
and to see which issues are fixed in the package - even if the
upstream version is still vulnerable.
Support backporting fixes
A distribution often has a different approach to fixing software
from an upstream project. Upstream projects are often content with
fixing their latest release(s). Distribution often support a
particular version of each software and need those to be fixed.
The Sources and Patches approach makes handling this a lot easier
(although it is lately being extended with the use of version
control like git(1)).
Allow 3rd party packages
Although RPM is designed to package a whole distribution it
explicitly supports 3rd parties to also provide packages without
becoming part of the distribution and their processes.
Rpmbuild can be run locally without the use of a big build system.
Dependencies are in large part automatic and target libraries
inside the packages instead of relying on conventions like package
names. This way 3rd party packages can be checked for
compatibility beyond them just claiming that they target the
distribution in question.
For proprietary softerware nosource packages allow to not ship the
sources but only the build instructions to keep proprietary source
private. They still can be used to generate binary packages in
combination with the sources.
Handle all system files
RPM takes ownership of all system files and their life cycle.
While packages can copy files in their scriptlets at installation
time this is strongly discouraged. Even files that are not
actually shipped can be added to the package as %ghost files to
allow RPM to handle them. All system files and directories should
be owned by a package.
Scriptlets should be used sparingly. Most use cases - like
updating caches and indexes - can be dealt with by using a central
filetrigger. Although these files may get altered they still
should be owned by a package.
Verify files
RPM keeps checksums of all files it maintains. Packages have
checksums and can and should be signed. Files that need to change
on disk - like config files, databases or indexes - can be marked
and are treated differently when being changed. While unchange
config files may be replaced changed ones will be retained or
backed up - depending on the way they have been packaged.
RPM in the Software handling stack
RPM sees itself as filling specific layers in the software
handling stack. It relies on build systems like make and the
upstream provided build scripts to orchestrate the actual build
and passes the acquiring and selection of the "right" packages up
to updaters like yum(8), dnf(8), zypper(8), etc.
The stack typically looks like this:
• Upstream build scripts using tools like maker, cmake, ant, ...
• rpmbuild for running those via an rpm-spec(5) file
• Build systems for installing build dependencies and keeping
track of build artifacts
• Package repositories offering binary packages
• Installers/Updaters selecting and downloading packages
• rpm checking for consistency and installing/updating the
packages
As such RPM is only a part in a larger set of tools and some users
may never actually interact with RPM directly.
Levels of control
Most things in RPM can be configured by macros. This allows
different actors to set them and overwrite what was set
previously.
Most basic are the defaults delivered by RPM upstream.
Distributions are able to overwrite them by patching or providing
new macro files. Packages can also ship macro files for other
packages to use as BuildRequires. Finally most build related
macros can also be overwritten in the rpm-spec(5) file - giving
the packager the last word.
There are a few command line options to allow users to influence
how packages are installed but their use is discouraged for the
most part and packages should be installed as they are.
rpm(8) rpmbuild(1) rpm-spec(5) rpm-macros(7) rpm-scriptlets(7)
http://www.rpm.org/
This page is part of the rpm (RPM Package Manager) project.
Information about the project can be found at
⟨https://github.com/rpm-software-management/rpm⟩. It is not known
how to report bugs for this man page; if you know, please send a
mail to [email protected]. This page was obtained from the
project's upstream Git repository
⟨https://github.com/rpm-software-management/rpm.git⟩ on
2026-01-16. (At that time, the date of the most recent commit
that was found in the repository was 2026-01-15.) If you discover
any rendering problems in this HTML version of the page, or you
believe there is a better or more up-to-date source for the page,
or you have corrections or improvements to the information in this
COLOPHON (which is not part of the original manual page), send a
mail to [email protected]
RPM 6.0.90 2026-01-16 RPM-DESIGN(7)
|
HTML rendering created 2026-01-16 by Michael Kerrisk, author of The Linux Programming Interface. For details of in-depth Linux/UNIX system programming training courses that I teach, look here. Hosting by jambit GmbH. |
|