rpm Package Manager in Fedora and Redhat

rpm plays exactly the same role on Fedora and RHEL-family systems that dpkg plays on Debian — it operates on a single, already-present .rpm file, performs no dependency resolution, and maintains the local package database directly. Everything dnf, covered in the next chapter, does at a higher level ultimately comes down to rpm doing this underlying work.

Installing A Local Package File

sudo rpm -i somepackage.rpm

-i installs a package archive directly — files copied, maintainer scripts run, entry recorded in the local database. Exactly like dpkg -i, if somepackage.rpm depends on something not currently installed, rpm reports the missing dependency and refuses to proceed, with no automatic resolution.

Removing: rpm -e

sudo rpm -e somepackage

-e (erase) removes a package. This is where rpm and dpkg genuinely diverge in approach — there’s no separate remove/purge distinction here. Instead, rpm handles configuration files through a different mechanism entirely, covered below.

How rpm Handles Modified Configuration Files: .rpmsave And .rpmnew

This is a real, practical difference worth understanding clearly rather than assuming it works the same way as the Debian side. If a configuration file has been modified locally since installation, rpm won’t simply overwrite or delete it during an upgrade or removal — it protects your changes automatically:

• During an upgrade, if the new package version ships an updated version of a config file you’ve modified, rpm installs the new default as filename.rpmnew, leaving your modified version in place untouched — you decide whether and how to merge the changes yourself.
• During removal, if a config file was modified from its originally-installed state, rpm saves it as filename.rpmsave rather than deleting it outright.

find /etc -name '*.rpmsave' -o -name '*.rpmnew'

This is a genuinely useful command to run periodically on any RPM-based system — these files accumulate silently over time, and finding them is the closest RPM-world equivalent to auditing for the leftover configuration dpkg -l’s rc state would reveal on the Debian side.

Querying: The -q Family

rpm -q and its variants are where most of your day-to-day interaction with rpm directly will actually happen.

rpm -q bash

bash-5.2.15-1.fc40.x86_64

Confirms whether a package is installed, and its exact version.

rpm -qa

Lists every installed package — the RPM equivalent of dpkg -l, though with less state information per line by default, since RPM’s simpler config-handling model means there’s no ii/rc-style distinction to show.

rpm -ql bash

/usr/bin/bash
/usr/share/doc/bash
/usr/share/man/man1/bash.1.gz

Exactly dpkg -L’s equivalent — every file a package owns, straight from the package database.

rpm -qf /usr/bin/bash

bash-5.2.15-1.fc40.x86_64

The reverse lookup — which package owns a given file — matching dpkg -S precisely.

rpm -qi bash

Full descriptive metadata for an installed package — description, size, install date, and more, matching dpkg -s.

Verifying Package Integrity: rpm -V

This is a feature worth calling out specifically, since it’s genuinely one of rpm’s strongest built-in capabilities: checking whether an installed package’s files still match what was originally installed.

rpm -V bash

No output at all means everything checks out — consistent with the “silence means success” convention from early in this course. If something’s changed, each modified file is listed with a code indicating exactly what differs:

S.5....T.  c /etc/bash.bashrc

Each character position reports on a different attribute — S for size, 5 for checksum (MD5), T for modification time, and several others — with a . meaning that attribute is unchanged. The c before the filename marks it as a configuration file. This is a genuinely powerful way to answer “has anything about this installed software been tampered with or modified since installation,” useful both for routine auditing and for security investigation.

Forcing Past Dependency Checks: --nodeps

sudo rpm -e --nodeps somepackage

--nodeps skips dependency checking entirely, allowing a removal (or installation) to proceed even if it would break something else that depends on it.

What rpm Deliberately Doesn’t Do

Exactly the same limitation as dpkg: no repository awareness, no searching, no automatic dependency resolution. Every one of those is what the next chapter’s tool, dnf, adds on top.

What’s Next

You can now install, remove, query, and verify .rpm packages directly, with the same level of precision dpkg offered on the Debian side — plus a genuine RPM-specific advantage in .rpmsave/.rpmnew config handling and built-in integrity verification. The next chapter covers dnf, the repository-aware, dependency-resolving tool you’ll actually use day to day on Fedora and RHEL-family systems.