RPM File — The Package Manager Behind It, Not Just the Archive Inside It

RPM Was Built to Track What's Installed, Not Just to Bundle Files

RPM — the Red Hat Package Manager — was created in 1997 by Erik Troan and Marc Ewing at Red Hat, replacing an earlier, more limited packaging tool called PMS. The single feature that separates RPM from a plain archive format is the database: every RPM-based system keeps a persistent record, historically stored using Berkeley DB, of every package that's installed, its exact version, which files belong to it, and what it depends on. Extracting the files out of an .rpm archive is trivial; what actually makes package management work is that database staying in sync with the filesystem every time something is installed, upgraded, or removed.

That Berkeley DB backend became a real liability over time, because Berkeley DB 5.x, the version RPM relied on, stopped receiving upstream maintenance years ago, and the newer Berkeley DB 6.x carries a license incompatible with how most Linux distributions want to ship software. Fedora addressed this directly starting with RPM 4.16, adding a SQLite-based database backend as an alternative, then making it the default in Fedora 33 (2020) — existing systems get converted automatically via an rpmdb-rebuild service that runs on first boot after the upgrade, and support for reading the old Berkeley DB format was phased down to read-only in Fedora 34 the following year.

Because that database is what package managers like dnf and yum actually query, a corrupted rpmdb is a categorically different problem than a corrupted archive file — it can make a system believe software is installed when it isn't, or block new installs with dependency errors that have nothing to do with the packages being installed at that moment. RPM ships its own recovery tooling for exactly this reason, distinct from anything related to extracting or repairing an individual .rpm file.

Packages Are Built From .spec Files, Not Assembled by Hand

An RPM file is never just zipped up manually. It's produced by rpmbuild reading a plain-text .spec file, a build recipe that lists the package's name, version, and release number, its dependencies, the shell commands needed to compile the source code, and — critically — the exact list of files that should end up inside the finished package. Rpmbuild runs its build steps inside a designated staging directory referenced in the spec file as %{buildroot}, so the actual system the build runs on never gets the software installed onto it directly; the finished package is assembled entirely from what lands in that isolated directory.

RPM's version-comparison scheme follows a specific three-part convention: epoch:version-release. The epoch is an optional integer that exists purely to force one version to be treated as newer than another when a project's own version-numbering scheme changes in a way that would otherwise look like a downgrade (for example, switching from date-based versions back to semantic ones) — most packages never set an epoch at all, and it defaults to being treated as absent. Version is the upstream project's own version string, and release is the distribution packager's own build counter, incremented every time the same upstream version gets repackaged with packaging fixes but no code changes.

Install scriptlets — %pre, %post, %preun, and %postun — are also written directly into the .spec file and get compiled into the package's Header section during the build, which is why a package's install-time behavior (creating a system user account, restarting a service, updating a font cache) is fully determined before the RPM is ever built, not decided later by whatever tool happens to install it.

What RPM's Package-Management Layer Actually Provides

• Gain — dependency resolution: the RPM database tracks what every installed package requires and provides, letting tools like dnf refuse an install that would break something else already on the system.
• Gain — delta RPMs for smaller updates: a .drpm file, built with the bsdiff algorithm via the makedeltarpm tool, stores only the binary difference between an old and new package version, typically around a third of the full package's size.
• Lose — cross-distribution portability: an RPM built for one distribution's library versions can fail to install cleanly on another RPM-based distribution with different dependency names or versions, unlike a plain archive that carries no such expectations at all.
• Gain — cryptographic verification before install: package managers check the GPG signature stored in the Signature section against trusted keys, rejecting a tampered package before any of its files are extracted.
• Cost — CPU overhead on the receiving end: delta RPMs trade bandwidth for processing time, since applying one requires rebuilding the full package locally with bsdiff's reverse operation, which is exactly why many distributions leave delta RPM support off by default.
• Gain — queryable metadata without installing anything: commands like rpm -qpi and rpm -qlp read a package's Header section directly, showing its description, dependencies, and full file list without ever touching the Payload.

RPM's Brief Run as an Official Linux Standard

The Linux Standard Base, a joint project among several Linux distributions under what became the Linux Foundation, released its first specification, LSB 1.0, on June 29, 2001 — and it explicitly named RPM as the standardized packaging format applications should ship in to be considered LSB-conforming. The LSB didn't require a distribution to be built on RPM internally, only that it could correctly process a package file in the RPM format, but the practical effect was that independent software vendors targeting multiple Linux distributions in the early 2000s were pushed toward building RPM packages as the common denominator, regardless of whether the vendor's own preferred distribution used RPM natively.

That LSB-driven push explains a detail that still confuses people today: Debian-based distributions, which use the unrelated .deb format for their own native package management, can still install RPM packages through tools like alien, which reads an RPM's Header metadata and repackages it as a .deb — a compatibility bridge that exists specifically because of the LSB era, even though the LSB project itself was eventually discontinued as active distributions diverged in practice from a single common standard.

RPM today remains the native package format for Red Hat Enterprise Linux, Fedora, CentOS Stream, openSUSE, SUSE Linux Enterprise, and Mandriva-derived distributions, while Debian, Ubuntu, and their derivatives use .deb instead — the two ecosystems have never merged, despite the LSB's early attempt to make RPM the universal answer.

Where RPM's Database Layer Actually Breaks in Practice

A well-documented failure mode is the rpmdb becoming corrupted after an interrupted install or an unexpected power loss mid-transaction, since the older Berkeley DB backend was never fully transactional — a system left in that state can report packages as installed that don't fully exist on disk, or refuse new installs with dependency conflicts that trace back to stale database records rather than the packages actually being requested. Rebuilding the database with rpm --rebuilddb is the documented fix, and it's precisely this class of unreliability that motivated Fedora's move to the SQLite backend, which is more resilient to exactly this kind of interruption.

A second recurring issue involves delta RPM application failing outright when the locally installed package's own files don't exactly match what the delta was generated against — since a .drpm is a binary diff computed against one specific known starting version, any unexpected difference in the currently installed package (from a manual file edit, for instance) makes the diff inapplicable, and the package manager has to fall back to downloading the full RPM instead.

A third pattern shows up specifically around alien-converted packages moving between RPM and DEB ecosystems: alien's own documentation has long described the packages it produces as of "questionable" reliability, since it can only translate dependency names and version syntax it recognizes, and library or package naming differences between the two ecosystems (openssl versus libssl, for instance) routinely produce a converted package with dependencies that don't resolve correctly on the target system.

RPM's Database Era Measured Against Its Legacy Backend

Common Questions About What an RPM File Actually Is

Is the RPM database part of the .rpm file itself?
No. The rpmdb lives elsewhere on the filesystem (traditionally under /var/lib/rpm) and gets updated when a package installs — the .rpm file itself only carries the package's own Header, Signature, and Payload, not the system-wide install record.

What's the difference between a package's version and its release number?
Version is the upstream project's own version string; release is the distribution packager's own counter, incremented whenever the same upstream code gets repackaged with packaging-only changes and no new upstream release.

Why did Fedora move away from Berkeley DB for the RPM database?
Berkeley DB 5.x, the version RPM used, had gone unmaintained upstream, and the newer 6.x version's license conflicts with how Fedora distributes software — SQLite, adopted as the default starting with Fedora 33, is both actively maintained and more resistant to corruption from interrupted installs.

Can a Debian-based system install an RPM package directly?
Not natively. Tools like alien can translate an RPM's Header metadata into a .deb package, but alien's own documentation describes the results as of questionable reliability, since dependency names often don't map cleanly between the two ecosystems.

What is a delta RPM and why isn't it always used?
A .drpm stores only the binary difference between two package versions using the bsdiff algorithm, cutting download size to roughly a third of the full package — but applying it takes real CPU time to rebuild the full package locally, which is why many distributions leave the feature off by default despite the bandwidth savings.