What Is an RPM Package and How Is It Structured?

An RPM package is the standard software distribution and installation format used by Red Hat Enterprise Linux and its derived distributions. This article explains what an RPM package is, its role in Linux software management, its file naming conventions, and a detailed breakdown of its internal architectural structure—from the legacy lead to the compressed payload containing the software files.

What Is an RPM Package?

RPM, which stands for RPM Package Manager (originally Red Hat Package Manager), is a package management system designed for Linux operating systems. An RPM package is essentially an archive file containing the files that make up a software application, along with metadata required for installation, upgrading, verification, and removal.

Distributions that use the RPM format include Red Hat Enterprise Linux (RHEL), Fedora, CentOS, AlmaLinux, Rocky Linux, and openSUSE. These systems use higher-level package managers like dnf or zypper to resolve dependencies, but the underlying packages installed on the system are RPM files.

RPM Naming Convention

RPM files typically follow a strict naming convention:

name-version-release.architecture.rpm

For example, in httpd-2.4.51-1.el9.x86_64.rpm:

• Name: httpd (the software program)
• Version: 2.4.51 (upstream source software version)
• Release: 1.el9 (the build/packaging release for Enterprise Linux 9)
• Architecture: x86_64 (the target hardware processor architecture)

The Internal Structure of an RPM File

Under the hood, an RPM package is a binary file composed of four distinct sections arranged sequentially:

1. The Lead

The Lead is a fixed-size, 96-byte header located at the very beginning of the RPM file. Originally created to identify the file format to the operating system's file command, it contains:

• Magic Number: Identifies the file as an RPM archive (\xed\xab\xee\xdb).
• RPM Version: The version of the RPM file format used to build the package.
• Package Type: Indicates whether the package is a binary package (0) or a source package (1).
• Architecture and OS tags: Legacy indicators for the target platform.

Note: Modern RPM utilities largely ignore the information in the Lead (aside from the magic number) in favor of data found in the Header section.

2. The Signature

The Signature section ensures the integrity and authenticity of the package. It allows the system administrator or package manager to verify that the package has not been corrupted and was issued by a trusted vendor.

• It uses an implementation of the OpenPGP standard (GPG keys) or checksums (such as SHA-256 or MD5).
• It contains an index and store structure, similar to the main Header, containing records that hash or sign the contents of the Header and Payload sections.

3. The Header (Metadata)

The Header contains all the operational metadata describing the package. This section is parsed by package managers like RPM, YUM, or DNF to evaluate compatibility and dependencies without extracting the software. It includes:

• Identification Data: Package name, version, release, summary, and license.
• Dependencies: Lists of capabilities the package requires (Requires), provides (Provides), or conflicts with (Conflicts).
• File Lists: The absolute destination paths, permissions, owners, and checksums of every file included in the payload.
• Pre/Post-Install Scripts: Shell scripts executed at various stages of the installation lifecycle (e.g., %pre, %post, %preun, and %postun).

4. The Payload

The Payload contains the actual files to be installed on the operating system.

• The payload is packaged as a standard cpio archive.
• The cpio archive is compressed to save disk space and bandwidth. Standard compression algorithms include gzip, bzip2, xz, or zstd.
• When an installation occurs, the RPM tool decompresses the payload and streams the cpio archive directly to the filesystem paths mapped out in the Header.