RPM Package Manager
RPM Package Manager is a free and open-source package management system. The name RPM refers to file format and the package manager program itself. RPM was intended primarily for Linux distributions; the file format is the baseline package format of the Linux Standard Base.
Although it was created for use in Red Hat Linux, RPM is now used in many Linux distributions. It has also been ported to some other operating systems, such as Novell NetWare, IBM's AIX, CentOS, Fedora, and Oracle Linux. All versions or variants of these Linux operating systems use the RPM Package Manager.
An RPM package can contain an arbitrary set of files. Most RPM files are “binary RPMs” containing the compiled version of some software. There are also “source RPMs” containing the source code used to build a binary package. These have an appropriate tag in the file header that distinguishes them from normal RPMs, causing them to be extracted to /usr/src on installation. SRPMs customarily carry the file extension “.src.rpm”.
History
RPM was originally written in 1997 by Erik Troan and Marc Ewing, based on,, and experiences.was written by Rik Faith and Doug Hoffman in May 1995 for Red Hat Software, its design and implementations influenced greatly by, a package management system by Faith and Kevin Martin in the fall of 1993 for the Bogus Linux Distribution. preserves the "Pristine Sources + patches" paradigm of, while adding features and eliminating arbitrary limitations present in the implementation. provides greatly enhanced database support for tracking and verifying installed packages
Features
For a system administrator performing software installation and maintenance, the use of package management rather than manual building has advantages such as simplicity, consistency and the ability for these processes to be automated and non-interactive. rpm uses Berkeley DB as the backend database although since 4.15 in 2019, it supports building rpm packages without Berkeley DB.Features of RPM include:
- RPM packages can be cryptographically verified with GPG and MD5
- Original source archive are included in SRPMs, making verification easier
- Delta update: PatchRPMs and DeltaRPMs, the RPM equivalent of a patch file, can incrementally update RPM-installed software
- Automatic build-time dependency evaluation.
Local operations
Repositories
RPMs are often collected centrally in one or more repositories on the internet. A site often has its own RPM repositories which may either act as local mirrors of such internet repositories or be locally maintained collections of useful RPMs.Front ends
Several front-ends to RPM ease the process of obtaining and installing RPMs from repositories and help in resolving their dependencies. These include:- yum used in Fedora, CentOS 5 and above, Red Hat Enterprise Linux 5 and above, Scientific Linux, Yellow Dog Linux and Oracle Linux
- DNF, introduced in Fedora 18, Red Hat Enterprise Linux 8 and CentOS Linux 8.
- up2date used in Red Hat Enterprise Linux, CentOS 3 and 4, and Oracle Linux
- Zypper used in Mer, MeeGo, openSUSE and SUSE Linux Enterprise
- urpmi used in Mandriva Linux, ROSA Linux and Mageia
- apt-rpm, a port of Debian's Advanced Packaging Tool used in Ark Linux, PCLinuxOS and ALT Linux
- Smart Package Manager, used in Unity Linux, available for many distributions including Fedora.
- , a command-line utility available in Red Hat Enterprise Linux
Local RPM installation database
Description
Whilst the RPM format is the same across different Linux distributions, the detailed conventions and guidelines may vary across them.Package filename and label
An RPM is delivered in a single file, normally with a filename in the format:For example, in the package filename, the is, the is, the is, and the is.
The associated source package would be named
RPMs with the extension do not depend on a particular CPU architecture. For example, these RPMs may contain graphics and text for other programs to use. They may also contain shell scripts or programs written in other interpreted programming languages such as Python.
The RPM contents also include a package label, which contains the following pieces of information:
- software name
- software version
- package release. This field is also often used for indicating the specific distribution the package is intended for by appending strings like "mdv" , "mga", "fc4", "rhl9", "suse100" etc.
- architecture for which the package was built
Library packaging
Libraries are distributed in two separate packages for each version. One contains the precompiled code for use at run-time, while the second one contains the related development files such as headers, etc. Those packages have "-devel" appended to their name field. The system administrator should ensure that the versions of the binary and development packages match.Binary format
The format is binary and consists of four sections:- The lead, which identifies the file as an RPM file and contains some obsolete headers.
- The signature, which can be used to ensure integrity and/or authenticity.
- The header, which contains metadata including package name, version, architecture, file list, etc.
- A file archive, which usually is in cpio format, compressed with gzip. The tool enables retrieval of the cpio file without needing to install the RPM package.
- * The Linux Standard Base requires the use of gzip, but Fedora 30 packages are xz-compressed and Fedora 31 packages might be zstd-compressed. Recent versions of RPM can also use bzip2, lzip, or lzma compression.
- * RPM 5.0 format supports using xar for archiving.
SPEC file
Spec files are usually distributed within SRPM files, which contain the spec file packaged along with the source code.
SRPM
A typical RPM is pre-compiled software ready for direct installation. The corresponding source code can also be distributed. This is done in an SRPM, which also includes the "SPEC" file describing the software and how it is built. The SRPM also allows the user to compile, and perhaps modify, the code itself.A software package could contain only platform independent scripts. In such a case, the developer could provide only an SRPM, which is still an installable RPM.
NOSRC
This is a special version of SRPM. It contains "SPEC" file and optionally patches, but does not include sources.Forks
, there are two versions of RPM in development: one led by the Fedora Project and Red Hat, and the other by a separate group led by a previous maintainer of RPM, a former employee of Red Hat.RPM.org
The rpm.org community's first major code revision was in July 2007; version 4.8 was released in January 2010, version 4.9 in March 2011, 4.10 in May 2012, 4.11 in January 2013, 4.12 in September 2014 and 4.13 in July 2015.This version is used by distributions such as Fedora, Red Hat Enterprise Linux and derivatives, openSUSE, SUSE Linux Enterprise, Unity Linux, Mageia, OpenEmbedded, Tizen and OpenMandriva Lx.
RPM v5
Jeff Johnson, the RPM maintainer since 1999, continued development efforts together with participants from several other distributions. RPM version 5 was released in May 2007.This version is used by distributions such as Wind River Linux, Rosa Linux, and OpenMandriva Lx and also by the OpenPKG project which provides packages for other common UNIX-platforms.
OpenMandriva Lx is going to switch back to rpm.org for 4.0 release.
OpenEmbedded, the last major user of RPM5, switched back to rpm.org due to issues in RPM5.
At since mid-2019 the website rpm5.org is not available. And the fork seems to cease to exist.