RPM, YUM, and DNF: Package Management on the RHEL Family

Package Management Basics, apt and Repositories, and dpkg and Dependencies all focused on the Debian/Ubuntu ecosystem. But RPM-based distributions — RHEL, CentOS Stream, Rocky Linux, AlmaLinux, and Fedora — are just as common in production, especially in enterprise environments. This article covers that ecosystem's core tools, mapped directly onto the Debian-side concepts you already know.

The Same Two-Layer Model, a Different Ecosystem

On the Debian side, dpkg is the low-level tool and apt is the high-level layer managing repositories and dependencies above it. The RPM family repeats exactly this structure:

dnf is the modern successor to yum — the default on RHEL 8+, Fedora, and Rocky/AlmaLinux. Older RHEL 7/CentOS 7 systems still use yum, but its command syntax is nearly identical, and on many current systems yum is itself simply an alias pointing to dnf.

rpm: The Low-Level Tool

Checking an Installed Package

rpm -q httpd

httpd-2.4.57-5.el9.x86_64

-q means query. If the package is not installed, rpm reports "package httpd is not installed".

Detailed Package Information

rpm -qi httpd

Equivalent to dpkg -s <package> — shows version, install date, size, and description.

Which Files a Package Installed

rpm -ql httpd

Equivalent to dpkg -L <package>.

Which Package Owns a File — the Reverse Direction

rpm -qf /usr/sbin/httpd

httpd-2.4.57-5.el9.x86_64

rpm -qf names the package a file already on disk came from — the direct equivalent of dpkg -S on the Debian side. For a file that is not yet installed, dnf provides answers the same question against the whole repository, which is how you discover which package to install to obtain a missing command or library:

dnf provides */httpd

Installing a .rpm File Directly

sudo rpm -ivh package-1.0-1.el9.x86_64.rpm

• -i — install;
• -v — verbose;
• -h — print progress markers (#).

Equivalent to dpkg -i package.deb — and, just like dpkg, dependencies are not resolved automatically:

dnf: The High-Level, Dependency-Resolving Tool

Searching for a Package

dnf search nginx

Equivalent to apt search.

Installing

sudo dnf install nginx

Equivalent to apt install. dnf automatically finds all required dependent packages from the repository, shows the list, and installs after confirmation.

Updating the System

sudo dnf check-update
sudo dnf update

Equivalent to the apt update && apt upgrade pair — the difference is that on dnf, refreshing repository metadata and upgrading packages are often combined into a single dnf update command (check-update only shows available updates without changing anything).

Removing

sudo dnf remove nginx

Equivalent to apt remove.

Listing Installed Packages

dnf list installed

Equivalent to dpkg -l.

Viewing a Package's Dependencies

dnf repoquery --requires nginx

Equivalent to apt-cache depends.

Configuring Repositories

On the RPM family, repositories are described in .repo files under /etc/yum.repos.d/ — the equivalent of Debian's /etc/apt/sources.list.d/:

[example-repo]
name=Example Repository
baseurl=https://repo.example.com/el9/x86_64/
enabled=1
gpgcheck=1
gpgkey=https://repo.example.com/RPM-GPG-KEY-example

• baseurl — the address where package files are located;
• gpgcheck=1 — makes signature verification mandatory;
• gpgkey — the address of the public key used for verification.

After adding a new repository, refresh the metadata cache:

sudo dnf makecache

Equivalent to apt update.

Transaction History and Rollback: dnf history

One genuine capability dnf has that apt does not build in is a full, queryable record of every transaction, plus the ability to undo one. Each install, update, or remove is logged as a numbered transaction:

sudo dnf history

ID     | Command line             | Date and time    | Action(s)      | Altered
-------------------------------------------------------------------------------
    14 | update                   | 2026-07-28 02:11 | Update         |     37
    13 | install nginx            | 2026-07-25 09:40 | Install        |      4

Inspect exactly what a given transaction changed, then reverse it if an update caused a regression:

sudo dnf history info 14
sudo dnf history undo 14

undo reverts the packages that transaction changed — downgrading what it upgraded and removing what it installed — which is the RHEL-family answer to the rollback problem Production Updates solves through snapshots and apt-mark hold on the Debian side. It is not a substitute for a real backup before a major upgrade, but for a single bad dnf update it is often the fastest clean recovery.

Terminology Table: APT ↔ DNF

Common Mistakes

Treating rpm -ivh as the Standard Way to Install

This low-level tool does not resolve dependencies. Standard installation should always go through dnf install <name>, from a repository.

Assuming yum and dnf Are Completely Different Tools

On modern systems, yum is frequently just an alias pointing to dnf; the two share nearly identical command syntax. Where older documentation references yum, substituting dnf directly usually works without changes.

Leaving gpgcheck=0 as a "Temporary" Fix

Verification disabled temporarily in a test environment migrating into a production configuration is a common, avoidable security mistake.

Exercises

1. On an RHEL-based test VM (Rocky Linux, for example), run dnf search, dnf install, and rpm -qi one at a time, and compare the results against their Debian-side equivalents.
2. List all files belonging to an installed package with rpm -ql, and identify a configuration file among them.
3. Create a new .repo file with gpgcheck=1 configured, then run dnf makecache.
4. Without looking, write out both sides of each row in the terminology table above from memory, then check your answers against it.

Verification criterion: for each exercise, you should be able to state the Debian-side equivalent of the RHEL-side command you just ran, and explain why rpm/dpkg share the same dependency-checking limitation.

Summary

On the RPM family, rpm is the low-level tool and dnf (or the older yum) is the high-level one — this exactly mirrors the structure of Debian's dpkg/apt pair. The main practical differences are command names and the repository file format (.repo versus sources.list); the underlying concepts and workflow are nearly identical. Knowing both ecosystems lets you adapt quickly to package management regardless of which distribution family a given production server runs.

References

• Red Hat Enterprise Linux 9: managing software packages: https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/9/html/configuring_basic_system_settings/managing-software-packages_configuring-basic-system-settings
• DNF documentation: https://dnf.readthedocs.io/en/latest/
• Linux man-pages: rpm(8): https://man7.org/linux/man-pages/man8/rpm.8.html
• Fedora Docs: dnf.conf and .repo files: https://dnf.readthedocs.io/en/latest/conf_ref.html