The RPM Family Tree

Chapter 5

RPM-Based Systems

dnf and yum on Fedora/RHEL — the other major package management family, covered for comparison and genuine understanding

Everything in Chapters 2-4 was Debian-family specific. Fedora, RHEL, and their derivatives use an entirely separate lineage — different package format, different tools, broadly equivalent concepts. This chapter maps the two families onto each other directly, since almost every apt concept already covered has a genuine RPM-world counterpart.

The RPM Family Tree

Fedora is the upstream, fast-moving testing ground; RHEL is the stable, commercially-supported downstream; Rocky/Alma are free, community-maintained RHEL-compatible rebuilds

The Direct Equivalents

Debian/APT concept	RPM equivalent
.deb file format	.rpm file format
apt (modern front end)	dnf (modern front end)
apt-get (older front end)	yum (older front end — dnf is its modern replacement)
dpkg (low-level engine)	rpm (low-level engine)
/etc/apt/sources.list	/etc/yum.repos.d/*.repo files

dnf is to yum exactly what apt is to apt-get

Same relationship pattern as Chapter 2's apt/apt-get distinction — dnf is the newer, friendlier front end, yum is the older tool it replaced (and still works as an alias to dnf on modern Fedora/RHEL specifically for backward compatibility with existing scripts and habits).

Everyday Commands — Directly Mirroring Chapter 2

$ # Refresh package metadata (dnf does this automatically before most operations,
$ # unlike apt where update is a deliberate separate step)
$ sudo dnf check-update

$ # Install a package
$ sudo dnf install nginx

$ # Remove a package
$ sudo dnf remove nginx

$ # Upgrade everything installed
$ sudo dnf upgrade

$ # Search for a package
$ dnf search "web server"

$ # Show detailed package information
$ dnf info nginx

$ # List installed packages
$ dnf list installed

dnf refreshes metadata automatically — there's no separate, mandatory "update" step like apt's

Unlike apt, where forgetting apt update before apt install means working from a stale package list (Chapter 2's most-confused command), dnf automatically checks for fresher metadata as part of normal operations — dnf check-update exists mainly to preview what updates are available, not as a mandatory prerequisite step the way apt update functions.

autoremove — Same Concept, Same Name

$ sudo dnf autoremove

Identical purpose to Chapter 2's apt autoremove — cleans up dependencies that were only installed automatically for a now-removed package and aren't needed by anything else.

Where dnf/RPM Genuinely Differs from apt/dpkg

Transaction history. dnf history shows every past package transaction with the ability to undo a specific one (dnf history undo <id>) — a more structured rollback mechanism than apt offers natively.
Built-in metadata refresh as part of normal operation, rather than a separate explicit step.
Different repository file format — individual .repo files in /etc/yum.repos.d/, with their own INI-style syntax, rather than apt's deb ... line format.

Chapter 5 Quick Reference

dnf ↔ apt; yum ↔ apt-get (older, dnf is its modern replacement); rpm ↔ dpkg
.rpm ↔ .deb file format
dnf install/remove/upgrade/search/info — directly mirror the apt verbs from Chapter 2
dnf refreshes metadata automatically — no separate mandatory "update" step like apt's
dnf autoremove — identical concept to apt autoremove
dnf history / dnf history undo — a more structured built-in rollback mechanism than apt natively offers
/etc/yum.repos.d/*.repo — the RPM-world equivalent of sources.list.d/
Next chapter: managing repositories on RedHat-based systems — repo files, EPEL, third-party repos