RPM (RPM Package Manager, originally Red Hat Package Manager) is both a binary package format and the low-level tool that installs, upgrades, queries, verifies and removes those packages on a Linux system. In Linux package management, RPM is the foundation of the Red Hat family, including Fedora, Red Hat Enterprise Linux, CentOS Stream, Rocky Linux and AlmaLinux, and of SUSE distributions such as openSUSE and SLES.
RPM works on individual package files and a local database of what is installed. It checks dependencies but does not download or resolve them from repositories; that job belongs to higher-level tools such as DNF on Fedora and RHEL or zypper on SUSE, which call the RPM library underneath.
What an RPM package contains
An .rpm file is a signed, compressed archive with structured metadata. The file begins with a short legacy lead, followed by a signature header, a main header with tagged metadata, and finally the payload that holds the files to install.
| Part | Content | Purpose |
|---|---|---|
| Lead | Fixed-size identification block | Legacy compatibility, file type detection |
| Signature header | OpenPGP signatures and digests | Proves origin and integrity |
| Main header | Name, version, dependencies, file list, scripts | Drives installation and queries |
| Payload | cpio archive compressed with zstd, xz or gzip | The actual files and directories |
Package files follow the NEVRA naming convention: name, epoch, version, release and architecture, as in httpd-2.4.62-1.el9.x86_64.rpm. The epoch is a hidden integer that overrides normal version comparison when upstream numbering changes, and the release counts packaging revisions of the same upstream version.
Packages also carry scriptlets such as %pre, %post, %preun and %postun, which run shell code before or after installation and removal, plus triggers that fire when another named package changes.
Everyday rpm commands
The rpm command is organized into modes such as install, query and verify. Query and verify modes are the ones administrators use most, because they answer what is installed and whether it has changed.
| Command | Action | Typical use |
|---|---|---|
| rpm -ivh pkg.rpm | Install a package file | Local package with no repository |
| rpm -Uvh pkg.rpm | Upgrade or install | Replacing an older version |
| rpm -e name | Erase an installed package | Removal without repository tools |
| rpm -qa | List all installed packages | Inventory and audits |
| rpm -qf /path/file | Find the owning package | Tracing an unknown file |
| rpm -ql name | List files in a package | Locating configuration and binaries |
| rpm -V name | Verify files against the database | Detecting modified or damaged files |
| rpm –import key | Import a signing key | Trusting a repository |
Verification output uses a compact code per file: S for size, 5 for digest, M for mode, T for modification time, among others. A line such as S.5....T. c /etc/ssh/sshd_config means a configuration file was edited, which is expected, whereas the same flags on a binary in /usr/bin deserve investigation.
How RPM compares with neighboring package tools
RPM occupies the same layer as dpkg on Debian systems: it handles package files and the installed database, while repository-aware front ends handle downloads and dependency resolution. The table places RPM among the other tools of the package management topic.
| Tool | Layer | Package format | Main distributions |
|---|---|---|---|
| RPM | Low-level | .rpm | Fedora, RHEL family, SUSE |
| DNF | High-level, repositories | .rpm | Fedora, RHEL 8 and later |
| zypper | High-level, repositories | .rpm | openSUSE, SLES |
| dpkg | Low-level | .deb | Debian, Ubuntu |
| APT | High-level, repositories | .deb | Debian, Ubuntu |
| Pacman | Combined low and high level | .pkg.tar.zst | Arch Linux |
A practical consequence is that installing a local file with rpm leaves dependencies unresolved. dnf install ./pkg.rpm installs the same file but pulls missing dependencies from enabled repositories, which is why the front end is the recommended route on modern systems.
Building packages with rpmbuild and spec files
RPM packages are produced by `rpmbuild` from a spec file, a text recipe that names the sources, describes how to build and install the software, and lists the files that belong in the package. A source package with the .src.rpm extension bundles the spec with its sources so anyone can rebuild the binary package.
| Section | Role |
|---|---|
| Preamble | Name, Version, Release, License, BuildRequires, Requires |
| %prep | Unpack sources and apply patches |
| %build | Compile the software |
| %install | Install into a temporary build root |
| %files | Declare packaged files and their attributes |
| %changelog | Record packaging history |
Dependencies are partly generated automatically: rpmbuild scans binaries for shared library requirements and scripts for interpreters. Since rpm 4.12, packages may also declare weak dependencies with Recommends: and Suggests:, which front ends install by default or offer without enforcing them.
Pitfalls when working with RPM
Problems with RPM usually arise from bypassing the repository layer or from mixing packages built for different distributions. The following points summarize what experienced administrators avoid.
- Using –nodeps or –force: these flags silence real conflicts and leave the system in an inconsistent state.
- Mixing distribution releases: a package built for one release may require library versions that do not exist on another.
- Installing unsigned packages: without signature checking, tampered packages install silently.
- Editing the database by hand: the RPM database should only change through rpm or its front ends;
rpm --rebuilddbrepairs index damage. - Expecting rpm -e to clean up dependencies: removal does not take away packages that were only pulled in as dependencies.
Configuration files marked with %config(noreplace) receive special treatment during upgrades: if the administrator has edited them, RPM keeps the edited file and writes the new default beside it with an .rpmnew suffix, which should be reviewed after every major update.
Understanding it simply
Think of an RPM file as a sealed parcel of software with a detailed packing slip. The slip says what the parcel contains, where each item goes, which other parcels it needs and who sealed it.
The rpm tool is the clerk who unpacks the parcel, puts every item in its place and writes it all into a register. Later the clerk can tell you which parcel any file came from and whether anything has been changed since delivery. Fetching missing parcels from the warehouse is the job of another helper, such as DNF.
Applied in practice
After a suspected intrusion on a Rocky Linux web server, a security engineer needs to know quickly whether system binaries were replaced. Reinstalling the server would destroy evidence, so the engineer starts with package verification.
Running rpm -Va compares every installed file against the size, digest, mode and ownership recorded in the RPM database. Most findings are edited configuration files marked with c, as expected. Two entries stand out: /usr/bin/ps and /usr/bin/ss both show changed digests, and rpm -qf confirms they belong to procps-ng and iproute.
The engineer copies the altered binaries for analysis, documents the result and rebuilds the server from a clean image. RPM verification turned a vague suspicion into concrete evidence in a few minutes, without any additional tooling installed on the compromised machine.