RPM-DESIGN(7)

# NAME
rpm-design - RPM design philosophy

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

# SEE ALSO
*rpm*(8) *rpmbuild*(1) *rpm-spec*(5) *rpm-macros*(7) *rpm-scriptlets*(7)

*http://www.rpm.org/*
