What is an RPM File?Linux Package

📦 What is an RPM File?

An RPM file is a software package for Linux. It bundles everything a program needs into one file so that Red Hat based systems can install, update and remove that software cleanly.

The name comes from the RPM Package Manager, originally the Red Hat Package Manager, which is the system that handles these packages. When you want to add a program to a distribution like Fedora, Red Hat Enterprise Linux or CentOS, one common way is to download a .rpm file and let the package manager unpack it into the right places on your system. Inside that single file sits the compiled program along with its supporting pieces, and a set of instructions describing what it is and what else it needs to run. That last part matters, because an RPM records the other packages it depends on, so the system can warn you or fetch them rather than leaving you with a half-working install.

If you have used Linux before, you can think of an RPM as the Red Hat world's answer to the .deb packages used on Debian and Ubuntu. If you are arriving from Windows, it is tempting to see an RPM as the Linux version of an .exe, but that comparison is misleading in an important way covered further down. The sections here walk through what an RPM actually holds, how it lines up against those other formats, and the simple commands that install one.

⚡ Quick Facts

🔎 What Is Inside an RPM

An RPM is really an archive with a purpose, and it is worth seeing what the package manager finds when it opens one, because that explains why an RPM install is so tidy.

Packed inside are the program's actual files, the compiled binaries that run, along with the libraries they rely on, any default configuration files, and documentation. Sitting alongside those is the metadata, a description of the package that names it, gives its version, and lists the other packages it needs in order to work. There is also a set of scripts the system can run at the right moments during installation or removal, for tasks like registering a service. Because all of this travels together, the package manager knows exactly what it placed on your system and where, which is what lets it later update or remove the software cleanly and leave almost nothing behind. Many packages also carry a digital signature made with a GPG key, so your system can confirm the file genuinely came from its publisher and has not been tampered with. Most RPMs you meet are binary packages holding ready-to-run software for a particular processor type, marked in the file name by an architecture such as x86_64, or by noarch when the contents do not depend on the processor. A separate kind, the source RPM ending in .src.rpm, holds the original code a package is built from rather than the finished program.

nginx-1.24.0.rpm   # one package file
 ├─ program files    # binaries, libraries, config, docs
 ├─ metadata         # name, version, description
 ├─ dependencies     # other packages it needs
 └─ GPG signature    # proof of authenticity

🔀 RPM vs DEB and EXE

Two comparisons come up constantly, one within Linux and one for anyone crossing over from Windows, and getting them straight clears up most of the confusion around RPM files.

Within Linux, RPM and DEB do the same job on different families. RPM is the package format for the Red Hat side, covering Fedora, Red Hat Enterprise Linux, CentOS and Rocky, while DEB is the format for the Debian side, covering Debian itself and Ubuntu and its relatives. A package built as an RPM will not install on Ubuntu as is, and a DEB will not install on Fedora, because each family expects its own format and its own package manager. The concepts are almost identical, so the main practical point is simply to download the version that matches your distribution.

The Windows comparison is where people go wrong. It is natural to treat an RPM like an .exe, since both are how you get software onto a machine, but they are not the same kind of thing. An .exe is the runnable program itself, whereas an RPM is a package that the system installs, a container of files and instructions rather than something you run directly. The closer Windows parallel is an installer package such as an .msi, which, like an RPM, hands its contents to a management system that puts everything in place and keeps track of it.

📥 How to Install an RPM File

There are two everyday ways to install an RPM, one through the desktop and one at the command line, and both are quick once you know them.

The graphical route is the gentlest. After you download an RPM from a project's website, double-click it and your distribution's software application, such as GNOME Software on Fedora, opens it and shows an Install button. Click that, enter your password when asked, and the software is added like any other app. The command line gives you more control and is the usual choice on servers. The recommended command uses your high-level package manager, which is dnf on current Fedora and Red Hat systems, because it installs the RPM and pulls in any packages it depends on at the same time. Older systems use yum in exactly the same way. There is also the lower-level rpm command, which installs the single file directly but does not fetch dependencies, so it can stop and tell you something is missing.

# Recommended: dnf resolves dependencies for you
$ sudo dnf install ./package.rpm

# Older Red Hat systems use yum the same way
$ sudo yum install package.rpm

# Low-level rpm: installs but does not fetch dependencies
$ sudo rpm -i package.rpm

# Upgrade an already installed package
$ sudo rpm -U package.rpm

🔧 Extract, Inspect and Remove

Installing is only part of the story, and the RPM tools let you look inside a package, check what it holds and take software back off again, all without guesswork.

Extract an RPM without installing it

Sometimes you want the files from a package but not a full install, perhaps to recover a single configuration file or to check what a download contains. The standard trick converts the package into an older archive form with the rpm2cpio tool and unpacks that with cpio, dropping the files into whatever folder you are in rather than onto the system. It even works on distributions that are not Red Hat based, since rpm2cpio travels with the rpm tooling. If you prefer to point and click, an archive manager such as Ark on KDE or the GNOME Archive Manager opens an RPM and lets you browse it like a zip.

# Convert to a cpio archive and unpack it here
$ rpm2cpio package.rpm | cpio -idmv

# Newer rpm can extract straight to a folder
$ rpm -i --extract package.rpm

Inspect and query a package

The rpm command can answer questions about a package before or after it goes on. Adding a p to a query points it at a file on disk, so you can read a package's details or list its contents without touching your system, while the same queries without the p look up software already installed. This is handy for confirming a version, seeing exactly which files a program will place, or finding out which package a stray file on your system came from. A related check, rpm followed by the -V option and a package name, compares the installed files against what was recorded when they went on, flagging anything whose size, permissions or contents have since changed.

# Show a downloaded package's info before installing
$ rpm -qip package.rpm

# List every file the package would place
$ rpm -qlp package.rpm

# Find which installed package owns a file
$ rpm -qf /path/to/file

Remove a package

Taking software off is the mirror image of installing it. The clean way is to let your high-level manager handle it with dnf remove followed by the package name, which also tidies up anything that was pulled in only for that program. The low-level equivalent is rpm with the e option. Whichever you use, the system checks whether other packages still rely on the one you are removing and stops rather than breaking them, which is exactly the safety you want.

🛠️ rpm vs dnf vs yum

Three command names show up around RPM files, and they are not competitors so much as layers, so it helps to know which does what.

At the bottom sits rpm, the low-level tool that installs, removes and queries a single package. It does exactly what you ask and no more, which means it will not go and find a missing dependency for you. Built on top of that idea are the high-level managers, yum and its modern successor dnf. These talk to software repositories, the online collections your distribution provides, so they can resolve dependencies automatically, download whatever a package needs, and keep everything updated. dnf, short for Dandified YUM, is the default on current Fedora and Red Hat releases and is faster and cleaner than the older yum, though the commands you type are nearly identical. In everyday use you reach for dnf or yum and let them lean on rpm underneath, saving the plain rpm command for the rare moment you want to act on one specific file and nothing else. Newer Fedora releases have begun moving to an updated version known as dnf5, and openSUSE, which also uses RPM packages, reaches for its own high-level manager called zypper, but the pattern is the same everywhere, a low-level tool for single packages with a smarter manager on top.

🌐 RPM vs Flatpak, Snap and AppImage

RPM is the traditional way to install software on Red Hat based Linux, but a newer group of formats now sits alongside it, and knowing how they differ helps you pick the right one.

An RPM is tied to a family of distributions and leans on the system's shared libraries, which keeps packages small and well integrated but means a package built for one distribution will not always suit another. The newer universal formats take a different path. Flatpak and Snap each bundle an application together with the pieces it needs so the same package runs across many distributions, trading a little extra size for that portability, and they add sandboxing that limits what an app can touch. AppImage goes furthest toward simplicity, packing everything into a single file you can download and run without installing at all. None of these replaces RPM outright. For core system software and anything your distribution ships, RPM through dnf remains the natural choice, while Flatpak, Snap and AppImage shine for desktop applications you want in the same form regardless of which Linux you happen to run.

💼 What RPM Files Are Used For

RPM files exist to make installing and managing Linux software dependable, and that shows up everywhere from a home Fedora desktop to a data centre full of servers.

Most of the time you never handle an RPM by hand, because your package manager pulls them from repositories whenever you install or update software. You meet a standalone .rpm file when a project offers its program directly on its website rather than through your distribution's repositories, which is common for commercial or newer applications. On servers, where consistency matters, administrators rely on RPM packages to roll out the same software across many machines and to know precisely what is installed. Developers who write software for Red Hat based systems build their releases as RPMs so that users can install them the standard way, complete with dependency information and a signature. Most of the RPMs a system uses live in its repositories, the curated online collections your distribution maintains, and a standalone file is the exception you download by hand. In all of these, the value is the same, an RPM turns a piece of software into a tidy, trackable package that a Linux system can install, verify and later remove without leaving a mess.

❓ Frequently Asked Questions