Learn Rocky Linux - Package Management with DNF5 & RPM

#Introduction

In the previous episode 3, you installed Rocky Linux and may have added a few packages. Now it's time to understand the machine behind package installation: DNF5 and RPM. On Rocky Linux 10, DNF5 is the default package manager — a modern version that's faster and more memory-efficient than its predecessors. Package management is the skill you'll use most as a sysadmin: installing a web server, updating the system, tracing dependency conflicts, verifying corrupted files, and even rolling back transactions — all of it revolves around dnf and rpm.

#DNF5 as the Default Package Manager

#Why DNF5

Rocky 8 and 9 use DNF, which itself evolved from yum. DNF5 is the successor, rewritten with a focus on speed and more efficient memory usage. On Rocky 10, dnf5 is the primary command, although most legacy commands still work as aliases.

dnf5 --version

#Basic Operations

dnf5 search nginx
dnf5 install nginx

dnf5 upgrade
dnf5 remove nginx

dnf5 install nginx resolves all dependencies automatically — the advantage of a package manager over installing from individual files. dnf5 upgrade updates all installed packages to the newest version available in the repositories and should be run regularly.

#Package Query and Information

To understand what's available and what's already installed, use repoquery and list:

dnf5 repoquery --available '*nginx*'
dnf5 list installed
dnf5 info nginx

dnf5 info nginx shows the package's description, version, size, and originating repository — a quick way to assess whether a package is worth installing before doing so.

#Autoremove to Keep the System Clean

When you remove a package, dependencies that are no longer needed may be left behind. dnf5 autoremove cleans up orphan packages that were only installed as dependencies:

dnf5 autoremove

This habit keeps the system lean and reduces the attack surface — the same principle as choosing Minimal Install in episode 3.

#Configuration and Repositories

#Configuration Structure

DNF5 configuration lives in /etc/dnf/dnf5.conf — this file controls global behavior such as transaction handling and cache contents:

dnf5 config-manager dump

Most settings don't need to change for normal use, but it's important to know where they live in case you later need to adjust the default behavior.

#Repository Directory

Repositories are defined in .repo files under /etc/yum.repos.d/. Each file contains one or more repository blocks with a name, URL, and settings like gpgcheck:

dnf5 repolist

dnf5 repolist --all

This is where you see BaseOS, AppStream, CRB, and Extras that we covered in episode 2, plus third-party repositories like EPEL if already added. GPG signature verification (gpgcheck=1) is always enabled in the official repositories — this protects you from packages tampered with in transit.

#RPM Fundamentals

#The RPM Package Format

RPM (Red Hat Package Manager) is the core package format. DNF5 works on top of RPM — DNF manages dependencies and transactions, while RPM handles the physical installation, metadata, and verification. Understanding RPM means understanding the foundation beneath DNF5.

#Querying with rpm

Query operations don't modify the system and are safe to run at any time:

rpm -q nginx
rpm -qa | head
rpm -qi systemd

rpm -q nginx shows the exact version of the installed package. rpm -qi systemd (info) shows the description, license, and installation time. To list the files owned by a package:

rpm -ql nginx

And to find out which package owns a file:

rpm -qf /etc/nginx/nginx.conf

#Integrity Verification

One of RPM's most valuable features is verification — comparing installed files with their original state at installation time:

rpm -V nginx

Output shows changes like S (size), M (mode), 5 (digest changed). If there's no output, all files are unchanged since installation. This verification is very useful for detecting corrupted or modified files — an early step in a security investigation.

#Installing RPM Files Manually

Sometimes you get a .rpm file directly, not from a repository. RPM can install it, but without automatic dependency resolution:

rpm -ivh package.rpm
rpm -Uvh package.rpm

-i for install, -U for upgrade, -h shows a progress bar. Remember: prefer letting DNF5 install local RPM files (via dnf5 install ./package.rpm) so dependencies are resolved properly.

#Extraction Without Installation

RPM stores files in the cpio format. To inspect a package's contents without installing it — for example, checking a config file that would be overwritten:

rpm2cpio package.rpm | cpio -idmv

rpm2cpio package.rpm | cpio -t

This technique is very helpful during audits or forensics: you can see exactly what a package will deploy.

#History and Rollback with DNF5

#Transaction History

Every DNF5 operation is recorded as a transaction. This history becomes an audit trail — what was installed, when, and by whom:

dnf5 history

dnf5 history info 14

#Transaction Rollback

If an update breaks the system, DNF5 can undo a specific transaction:

dnf5 history undo 14

dnf5 history rollback 12

dnf5 history rollback restores the system to its state after a given transaction — a very reassuring tool when a weekly update causes trouble.

#Closing

In this episode 4, you mastered the foundations of Rocky Linux package management: daily DNF5 operations like install, remove, search, and upgrade, the configuration structure at /etc/dnf/dnf5.conf and repositories at /etc/yum.repos.d/, RPM fundamentals for querying, verifying, and extracting, plus transaction history and rollback as a safety net.

Key takeaways:

• DNF5 is Rocky 10's default package manager; use install, remove, upgrade, search, and repoquery.
• Autoremove keeps the system clean of unused orphan dependencies.
• Repositories are defined in /etc/yum.repos.d/; make sure gpgcheck=1 is always enabled.
• rpm -q, rpm -V, and rpm2cpio are the fundamentals for querying, verifying, and extracting packages.
• dnf5 history undo and rollback turn a problematic upgrade into a calm moment.

In the next episode 5, we will discuss repositories, modules, and AppStream — how BaseOS and AppStream work, module streams that allow multiple application versions to coexist, third-party repositories like EPEL, and the conceptual difference between multi-version in AppStream and multi-repository. See you in the next episode!