Jump to content

RPM Package Manager

From Alfawiki
RPM Package Manager
Company typeFree and open-source software
IndustryPackage management system
Founded1997
FounderErik Troan, Marc Ewing
Area served
Linux distributions and other platforms
Key people
Erik Troan, Marc Ewing
ProductsRPM package format and package management tool
Websiterpm.org

RPM (initially standing for Red Hat Package Manager and now a recursive acronym for RPM Package Manager) is a free and open-source package management system. The term RPM denotes both the file format and the package management tool itself. Designed mainly for Linux distributions, its file format serves as the standard package format according to the Linux Standard Base.

Originally developed for Red Hat Linux, RPM has since been adopted by numerous distributions including PCLinuxOS, Fedora Linux, AlmaLinux, CentOS, openSUSE, OpenMandriva, and Oracle Linux. Additionally, it has been adapted for other platforms such as Novell NetWare (version 6.5 SP3), IBM AIX (version 4),IBM i, and ArcaOS.

RPM packages can encompass a variety of file types. The majority are "binary RPMs" (BRPMs), which contain precompiled software, whereas "source RPMs" (SRPMs) provide source code intended for building binaries. SRPMs are distinguished by specific tags in their headers and typically extract to /usr/src upon installation, often using extensions like ".src.rpm" or ".spm" on systems with restricted file naming conventions.

History

RPM was first created in 1997 by Erik Troan alongside Marc Ewing, drawing on knowledge gained from earlier package management tools such as , , and . 

was developed in 1995 by Rik Faith and Doug Hoffman for Red Hat Software, inspired by , a package management system designed by Faith and Kevin Martin in 1993 for the Bogus Linux Distribution.  retained the "Pristine Sources + patches" methodology from , while introducing enhancements and eliminating arbitrary constraints. It also improved database capabilities to better track and verify installed packages.

Features

For system administrators, managing packages via RPM offers benefits over manual compilation, including greater ease, uniformity, and automation. RPM employs Berkeley DB as its underlying database; however, since version 4.15 (2019), it allows package construction without Berkeley DB support (–disable-bdb).

Prominent features of RPM include:

  • Package verification through cryptographic methods such as GPG and MD5
  • Inclusion of original source archives (e.g., , ) within SRPMs to facilitate verification
  • Capability for incremental updates using PatchRPMs and DeltaRPMs
  • Automatic resolution of build-time dependencies

Local operations

RPM packages may be sourced from official distributions (for instance, Red Hat Enterprise Linux) or third-party providers (such as RPM Fusion for Fedora Linux). Circular dependencies among RPM packages—often referred to as "dependency hell"—can complicate installation processes; resolving these issues typically requires specifying all dependent packages within a single command.

Repositories

RPM files are frequently stored in centralized online repositories. These repositories are commonly maintained by sites either as local mirrors of internet repositories or as curated collections of valuable RPM packages.

Front ends

Various front-ends exist to streamline the process of acquiring and installing RPM packages from repositories while managing dependencies effectively. Notable tools include:

Local RPM installation database

The RPM database, located in , utilizes Berkeley DB to maintain records of installed packages. It consists of a main database () containing metadata about installed RPMs, along with several index databases designed to accelerate query performance. This system tracks every file added or altered during package installation, facilitating dependable uninstallation processes. Should the database become corrupted—such as from an abrupt termination of the RPM client—the indexes can be reconstructed using .

Description

Although the RPM format remains uniform across Linux distributions, each distribution applies its own specific standards and practices.

Package filename and label

RPM packages are distributed as single files, generally named as follows:

for source packages, or
for binary packages.

For instance, incorporates as the package name, representing the version, indicating the release, and specifying the architecture. The matching source package is .

Packages with the extension are architecture-neutral and often include graphics, text files, or scripts written in interpreted languages such as Python.

The RPM’s label comprises:

  • software name
  • software version (derived from the original upstream source)
  • package release (denoting rebuild iterations or target distributions, e.g., "mdv" for Mandriva Linux, "fc4" for Fedora Core 4)
  • intended architecture (examples include i386, i686, x86_64, ppc)

These label components might not always match those in the filename.

Library packaging

For each library version, two separate packages exist: one containing precompiled runtime binaries and another with development resources such as headers, identified by the "-devel" suffix. System administrators must ensure both packages correspond to the same version.

Binary format

RPM files are binary archives structured into four parts:

  • The lead section identifies the file as an RPM and holds legacy headers.
  • The signature section ensures package integrity and/or authenticity.
  • The header contains metadata like package name, version, architecture, and a list of included files.
  • The payload is an archive of files, commonly in cpio format compressed using gzip. Utilities such as can extract this archive without performing installation.

While the Linux Standard Base requires gzip compression, Fedora 30 switched to xz, with Fedora 31 potentially adopting zstd. Newer RPM versions also support compression formats including bzip2, lzip, and lzma. RPM 5.0 adds support for archiving via xar.

SPEC file

The blueprint for building an RPM package is defined in a spec file, which has a ".spec" extension. This file specifies the package name, version, RPM revision number, build instructions, installation steps, cleanup commands, and a changelog. Using rpmbuild, multiple packages can be generated from one spec file.

Spec files are commonly bundled within SRPMs that include both the spec file and source code.

SRPM

While standard RPMs offer precompiled software ready for installation, source code is distributed through SRPMs that contain the spec file outlining build procedures. SRPMs enable users to compile or customize the software.

In cases where scripts are platform-independent, developers may provide only an SRPM package that can still be installed as an RPM.

NOSRC

This is a distinct SRPM type that includes the spec file and, optionally, patches but excludes source code, typically due to licensing constraints.

Forks

By mid-2010, two separate RPM development lines had emerged: one driven by the Fedora Project in collaboration with Red Hat, and another maintained by a former Red Hat employee who previously managed RPM.

RPM.org

Starting in July 2007, the rpm.org community introduced significant releases: versions 4.8 (2010), 4.9 (2011), 4.10 (2012), 4.11 (2013), 4.12 (2014), and 4.13 (2015).

These releases are compatible with distributions such as Fedora Linux, Red Hat Enterprise Linux and its derivatives, openSUSE, SUSE Linux Enterprise, Unity Linux, Mageia, OpenEmbedded, Tizen, and OpenMandriva Lx.

RPM v5 (Discontinued)

Jeff Johnson maintained RPM version 5 from 1999, with its initial release in May 2007.

This version was utilized by Wind River Linux up to version 10, Rosa Linux, OpenMandriva Lx (which transitioned to rpm5 in 2011), and the OpenPKG initiative for UNIX systems.

OpenMandriva Lx switched back to rpm.org starting with its 4.0 version. Similarly, OpenEmbedded reverted to rpm.org due to challenges encountered with RPM5.

See also

External links

  1. ↑ Lua error in Module:Citation/CS1/Configuration at line 2123: attempt to index field '?' (a nil value).
  2. ↑ Lua error in Module:Citation/CS1/Configuration at line 2123: attempt to index field '?' (a nil value).
Retrieved from "https://www.alfawiki.org/index.php?title=RPM_Package_Manager&oldid=27339"