RPM Package Manager
|It has been suggested that SRPM be merged into this article or section. (Discuss)|
|This article needs additional citations for verification. |
Please help improve this article by adding reliable references. Unsourced material may be challenged and removed. (June 2009)
|Original author(s)||Red Hat|
|Developer(s)||Community & Red Hat|
|Stable release||4.8.1 / June 11, 2010 (2010-06-11)|
|Operating system||GNU/Linux, Unix-like|
|License||GNU General Public License|
RPM Package Manager is a package management system. The name RPM refers to two things: software packaged in the .rpm file format, and the package manager itself. RPM was intended primarily for GNU/Linux distributions; the file format is the baseline package format of the Linux Standard Base.
Originally developed by Red Hat for Red Hat Linux, RPM is now used by many GNU/Linux distributions. It has also been ported to some other operating systems, such as Novell NetWare (as of version 6.5 SP3) and IBM's AIX as of version 4.
Originally standing for "Red Hat Package Manager", RPM now stands for "RPM Package Manager", a recursive acronym.
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.
A typical RPM repository (the place where the packages are made available publicly) contains thousands of free applications.
Features of RPM include:
- RPM packages can be cryptographically verified with GPG and MD5
- Original source archive(s) (e.g. .tar.gz, .tar.bz2) are included in SRPMs, making verification easier
- PatchRPMs and DeltaRPMs, the RPM equivalent of a patch file, can incrementally update RPM-installed software
 Local operations
Packages may come from within a particular distribution (say Red Hat Linux) or be built for it by other parties (for example Freshrpms for Fedora). Circular dependencies among mutually dependent RPMs (so-called 'dependency hell') can be problematic; in such cases a single installation command needs to specify all the relevant packages.
 Front ends
There are several front ends to RPM that ease the process of obtaining and installing RPMs and in resolving their dependencies. These include:
- yum used in Fedora, CentOS-5, Red Hat Enterprise Linux 5 and above, Scientific Linux, Yellow Dog Linux and Oracle Enterprise Linux
- up2date used in Red Hat Enterprise Linux and CentOS (CentOS-3 and CentOS-4).
- Synaptic Package Manager used in PCLinuxOS
- Zypper used in openSUSE, SUSE Linux Enterprise and Ark Linux
- urpmi used in Mandriva Linux
- apt-rpm, a port of Debian's Advanced Packaging Tool (APT)
- Smart Package Manager, used in Unity Linux, available for many distributions including Fedora
 Local RPM installation database
Working behind the scenes of the package manager is the RPM database, stored in
/var/lib/rpm. It uses Berkeley DB as its back-end. It consists of a single database (
Packages) containing all of the meta information of the installed rpms. Multiple databases are created for indexing purposes, replicating data to speed up queries. The database is used to keep track of all files that are changed and created when a user (using RPM) installs a package, thus enabling the user (via RPM) to reverse the changes and remove the package later. If the database gets corrupted (which is possible if the RPM client is killed), the index databases can be recreated with the
rpm --rebuilddb command.
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 in the format:
Source code may also be distributed in RPM packages; the architecture part is specified as <src>:
RPMs with the noarch.rpm extension refer to packages which do not depend on a certain computer's architecture. These include graphics and text for another program to use, and programs written in interpreted programming languages such as Python programs and shell scripts.
The RPM contents also include a package label, which contains the following pieces of information:
- the software name
- the software version (the version taken from original "upstream" source of the software)
- the package release (the number of times the package has been rebuilt using the same version of the software). This field is also often used for indicating the specific distribution the package is intended for by appending strings like "mdv" (formerly, "mdk") (Mandriva Linux), "fc4" (Fedora Core 4), "rhl9" (Red Hat Linux 9), "suse100" (SUSE Linux 10.0) etc.
- the architecture the package was built for (i386, i686, athlon, ppc, etc.)
The package label does not necessarily need to match the name of the file.
 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.
The format is binary and consists of four sections:
- The lead 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 contains metadata including package name, version, architecture, file list, etc..
- A file archive, which usually is in cpio format, compressed with gzip. The rpm2cpio tool enables retrieval of the cpio file without needing to install the RPM package.
 Spec file
The "recipe" for creating an RPM package is a spec file. Spec files end in the ".spec" suffix and contain the package name, version, RPM revision number, steps to build, install, and clean a package, and a changelog. Multiple packages can be built from a single RPM spec file, if desired. RPM packages are created from RPM spec files using the rpmbuild tool.
Spec files are usually distributed within SRPM files, which contain the spec file packaged along with the source code.
As of June 2010[update], 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. Both projects currently call themselves the "official" version of RPM.
The rpm.org community's first major code revision was in July 2007; version 4.8 was released in January 2010.
 RPM v5
The RPM maintainer since 1999, Jeff Johnson, continued development efforts together with participants from several other distributions. RPM version 5 was released in May 2007.
 See also
- Autopackage - a "complementary" package management system
- dpkg - package management system used by Debian and its derivatives
- List of Linux distributions
- Portage - package management system used by Gentoo
- pkg-config - queries libraries to compile software from its source code
- ^ a b "Maximum RPM: Taking the Red Hat Package Manager to the Limit". rpm.org. http://rpm.org/max-rpm/s1-rpm-file-format-rpm-file-format.html. Retrieved 2008-02-29.
- ^ "Welcome to freshrpms.net. Simple, clean... and rpm packages". freshrpms.net. http://freshrpms.net/. Retrieved 2008-02-29.
- ^ "Repair an RPM database safely". http://22.214.171.124/search?q=cache:OC_1qQm4_isJ:rpm.org/hintskinks/repairdb/. Retrieved 2008-10-10.
- Red Hat RPM Guide from the Fedora project.
- RPM.org project home page
- RPM5 Package Manager homepage
- RPM and DPKG command reference
- The story of RPM by Matt Frye in Red Hat Magazine
- Advanced RPM query strings
- Video tutorials for Building and Patching the RPMs