Open Access Articles- Top Results for RPM Package Manager

RPM Package Manager

RPM Package Manager (RPM)
Original author(s) Erik Troan, Marc Ewing,[1]
Red Hat
Developer(s) Community & Red Hat[2][3]
Initial release 1997; 23 years ago (1997)[1]
Stable release 4.12 / 16 September 2014; 5 years ago (2014-09-16)
Written in C, Perl[4]
Operating system Linux, Unix-like
Type Package management system
License GPL

RPM Package Manager (RPM) (originally Red Hat Package Manager; now a recursive initialism) is a package management system.[5] The name RPM variously refers to the .rpm file format, files in this format, software packaged in such files, and the package manager itself. RPM was intended primarily for Linux distributions; the file format is the baseline package format of the Linux Standard Base.

Even though it was created for use in Red Hat Linux, RPM is now used in 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).

An RPM package can contain an arbitrary set of files. The larger part of RPM files encountered are “binary RPMs” (or BRPMs) containing the compiled version of some software. RPM files however may also contain the source code, then called “source RPMs” (or SRPMs) used to produce a package. SRPMs have an appropriate tag in the file header that distinguishes them from normal (B)RPMs, causing them to be extracted to /usr/src on installation. SRPMs also customarily carry the file extension “.src.rpm” (.spm on file systems limited to 3 extension characters, i.e. old DOS FAT).


RPM was originally written in 1997 by Erik Troan and Marc Ewing,[1] based on pms, rpp, and pm experiences.

pm was written by Rik Faith and Doug Hoffman in May 1995 for Red Hat Software. The design and implementation of pm was influenced greatly by previous experience with pms(1), a Package Management System designed and implemented by Rik Faith and Kevin Martin in the fall of 1993 for the Bogus Linux Distribution. pm preserves the "pristine sources + patches" paradigm of pms, while adding features and eliminating arbitrary limitations present in the implementation. pm provides greatly enhanced database support for tracking and verifying installed packages[6][7][4]


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.

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
  • Automatic build-time dependency evaluation.

Local operations

Packages may come from within a particular distribution (for example Red Hat Enterprise Linux) or be built for it by other parties (for example RPM Fusion for Fedora).[8] Circular dependencies among mutually dependent RPMs (so-called "dependency hell") can be problematic;[9] in such cases a single installation command needs to specify all the relevant packages.


RPMs are often collected centrally in one or more repositories on the internet. A local site often has its own local 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:

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.[12]


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:


such as:


where <name> is libgnomeuimm-2.0.

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:

  • software name
  • software version (the version taken from original upstream source of the software)
  • 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), "mga" (Mageia), "fc4" (Fedora Core 4), "rhl9" (Red Hat Linux 9), "suse100" (SUSE Linux 10.0) etc.
  • architecture for which the package was built (i386, i686, x86_64, ppc, etc.)

The package label fields do not need to match the filename.

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:[5]

  • 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 (the payload), 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.[13]
    • More recent versions of RPM can also use bzip2, lzip,[14] lzma, or xz compression.
    • RPM 5.0 format supports using xar for archiving.

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.


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 may contain only scripts that are architecture-independent. In such a case only an SRPM may be available; this is still an installable RPM.


As of June 2010, 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.

The community's first major code revision was in July 2007; version 4.8 was released in January 2010, version 4.9 in March 2011 and 4.10 in May 2012.

This version is used by distributions such as Fedora, Red Hat Enterprise Linux, openSUSE and SUSE Linux Enterprise, Mageia,[15] and formerly Mandriva (until 2010.2).

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.

This version is used by distributions such as Unity Linux, Wind River Linux, Rosa Linux, and OpenMandriva Lx (former Mandriva Linux which switched to rpm5 in 2011[16]) and also by the OpenPKG project which provides packages for other common UNIX-platforms.

See also

  • Autopackage — a "complementary" package management system
  • Delta ISO — an ISO image which contains RPM Package Manager files
  • dpkg — package management system used by Debian and its derivatives
  • List of Linux distributions
  • Portage — package management system used by Gentoo
  • Ports and Packages — FreeBSD's package management system
  • Ports and Packages — OpenBSD and NetBSD package management system
  • pkg-config — queries libraries to compile software from its source code
  • pkgsrc — package management system focusing on NetBSD, but available for Solaris, Linux, Darwin (Mac OS X), FreeBSD, OpenBSD, IRIX, BSD/OS, AIX, Interix (Microsoft Windows Services for Unix), DragonFlyBSD, OSF/1, HP-UX, QNX, and Haiku


  1. ^ a b c "RPM Project Roadmap". Retrieved 2011-12-11. 
  2. ^ "RPM -- plans, goals, etc.". Max Spevack <mspevack redhat com>. Retrieved 2011-01-20. 
  3. ^ " FAQ". Retrieved 2013-08-25. 
  4. ^ a b Bailey, Edward C. (2000). "Chapter 1: An Introduction to Package Management". Maximum RPM: Taking the Red Hat Package Manager to the Limit. Red Hat, Inc. pp. 22–25. ISBN 978-1888172782. Retrieved 2013-08-13. 
  5. ^ a b Bailey, Edward C. (2000). "Appendix A: Format of the RPM File". Maximum RPM: Taking the Red Hat Package Manager to the Limit. Red Hat, Inc. pp. 325–336. ISBN 978-1888172782. Retrieved 2010-11-22. 
  6. ^ "RPM Guide-RPM - Design Goals". Retrieved 2014-04-14. 
  7. ^ "BOGUS Announce". Retrieved 2014-04-14. 
  8. ^ "RPM Fusion". Retrieved 2010-11-22. 
  9. ^ "An Analysis of RPM Validation Drift" (PDF). USENIX Association. Retrieved 2011-03-15. 
  10. ^ "Zypper - MeeGo wiki". Retrieved 2014-04-14. 
  11. ^ "FAQs: About the Projects". Ark Linux Official Site. Retrieved 2014-04-14. 
  12. ^ "Repair an RPM database safely". Retrieved 2011-11-11. 
  13. ^ "Supplemental Packaging Software". Fedora Project. Retrieved 2011-11-11. 
  14. ^ "Add lzip support". Retrieved 2013-10-24. 
  15. ^ "Mageia 3 Release Notes: Package management", <span /><span />, 2013-05-19, retrieved 2014-04-14. 
  16. ^ Bodnar, Ladislav & Smith, Jesse (2010-11-22), "DistroWatch Weekly", <span />DistroWatch<span />, retrieved 2010-11-22. 

External links