| RPM Package Manager (RPM) | |
|---|---|
 | |
| Original authors | Erik Troan,Marc Ewing,[1]Red Hat |
| Developers | Community &Red Hat[2][3] |
| Initial release | 1997; 29 years ago (1997)[1] |
| Stable release | |
| Written in | C,C++,Perl[5] |
| Operating system | Linux,Unix-like |
| Available in | 41 languages[6] |
| Type | Package management system |
| License | GPL |
| Website | rpm |
| Repository | |
RPM (originallyRed Hat Package Manager, now arecursive acronym forRPM Package Manager) is afree and open-sourcepackage management system.[7] The name RPM refers to the.rpmfile format and the package manager program itself. RPM was intended primarily forLinux distributions; the file format is the baseline package format of theLinux Standard Base.
Although it was created for use inRed Hat Linux, RPM is now used in manyLinux distributions such asPCLinuxOS,Fedora Linux,AlmaLinux,CentOS,openSUSE,OpenMandriva andOracle Linux. It has also been ported to some otheroperating systems, such asNovell NetWare (as of version 6.5 SP3),IBM's AIX (as of version 4),[8]IBM i,[9] andArcaOS.[10]An RPM package can contain an arbitrary set of files. Most RPM files are "binary RPMs" (or BRPMs) containing the compiled version of some software. There are also "source RPMs" (or SRPMs) containing thesource code used to build a binary package. These 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 customarily carry the file extension ".src.rpm" (.spm on file systems limited to 3 extension characters, e.g. old DOSFAT).
RPM was originally written in 1997 by Erik Troan andMarc Ewing,[1] based onpms,rpp, andpm experiences.
pm was written by Rik Faith and Doug Hoffman in May 1995 for Red Hat Software, its design and implementations were influenced greatly bypms, a package management system by Faith and Kevin Martin in the fall of 1993 for the Bogus Linux Distribution.pm preserves the "Pristine Sources + patches" paradigm ofpms, while adding features and eliminating arbitrary limitations present in the implementation.pm provides greatly enhanced database support for tracking and verifying installed packages.[5][11][12]
For asystem 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 usesBerkeley DB as the backend database although since 4.15 in 2019, it supports building rpm packages without Berkeley DB (–disable-bdb).[13]
Features of RPM include:
.tar.gz,.tar.bz2) are included in SRPMs, making verification easierPackages may come from within a particular distribution (for exampleRed Hat Enterprise Linux) or be built for it by other parties (for exampleRPM Fusion for Fedora Linux).[14] Circular dependencies among mutually dependent RPMs (so-called "dependency hell") can be problematic;[15] in such cases a single installation command needs to specify all the relevant packages.
RPMs are often collected centrally in one or morerepositories 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.
Severalfront-ends to RPM ease the process of obtaining and installing RPMs from repositories and help in resolving their dependencies. These include:
rpmquery, a command-line utility available in (for example) Red Hat Enterprise Linuxlibzypp, forSailfish OSWorking behind the scenes of the package manager is the RPM database, stored in/var/lib/rpm. It usesBerkeley 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 iskilled), the index databases can be recreated with therpm --rebuilddb command.[18]
Whilst the RPM format is the same across differentLinux distributions, the detailed conventions and guidelines may vary across them.
An RPM is delivered in a single file, normally with a filename in the format:
<name>-<version>-<release>.src.rpm for source packages, or<name>-<version>-<release>.<architecture>.rpm for binaries.For example, in the package filenamelibgnomeuimm-2.0-2.0.0_3.i386.rpm, the<name> islibgnomeuimm, the<version> is2.0, the<release> is2.0.0_3, and the<architecture> isi386.The associated source package would be namedlibgnomeuimm-2.0-2.0.0_3.src.rpm
RPMs with thenoarch.rpm 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 containshell scripts or programs written in other interpreted programming languages such asPython.
The RPM contents also include apackage label, which contains the following pieces of information:
The package label fields do not need to match the filename.
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:[7]
rpm2cpio tool enables retrieval of the cpio file without needing to install the RPM package.[19]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.[example needed] 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 could contain only platform independent scripts. In such a case, the developer could provide only an SRPM, which is still an installable RPM.
This is a special version of SRPM. It contains "SPEC" file and optionally patches, but does not include sources (usually because of license).[22]
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 previousmaintainer of RPM, a former employee of Red Hat.
Therpm.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 asFedora Linux,Red Hat Enterprise Linux andderivatives,openSUSE,SUSE Linux Enterprise,Unity Linux,Mageia,[23]OpenEmbedded,Tizen andOpenMandriva Lx (formerlyMandriva).
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 was used by distributions such asWind River Linux (until Wind River Linux 10), Rosa Linux, andOpenMandriva Lx (formerMandriva Linux which switched to rpm5 in 2011[24]) and also by theOpenPKG project which provides packages for other common UNIX-platforms.
OpenMandriva Lx has switched back to rpm.org[25] for 4.0 release.[needs update]
OpenEmbedded, the last major user of RPM5, switched back to rpm.org due to issues in RPM5.[26][27]
Mandriva looks to abandon the unmaintained RPM 4.x series and replace it with RPM 5.x for better package management.
| dpkg | |
|---|---|
| RPM | |
| Embedded systems |
|
| Distribution-agnostic | |
| Others (binary) | |
| Others (source) | |
| Front-ends | |
| Related topics | |
Italics= inactive or discontinued | |
| Archiving only | |
|---|---|
| Compressing only | |
| Archiving and compressing | |
| Software packaging and distributing | |
| Document packaging and distributing | |
