DNF is the high-level package manager used by Fedora, Red Hat Enterprise Linux, CentOS Stream, AlmaLinux, Rocky Linux and related distributions to install, update and remove RPM packages from configured repositories. In Linux package management, DNF sits above the low-level RPM tool: it downloads metadata, resolves dependencies, plans a transaction and then hands the actual installation to the RPM library.
DNF replaced the older YUM tool, and the name originally stood for Dandified YUM. Since Fedora 41, the default implementation is DNF5, a rewrite in C++ that keeps the familiar command syntax while improving speed and memory use.
How DNF resolves and applies transactions
Every DNF operation follows the same pipeline of metadata, solving and execution. DNF first loads repository metadata, which lists every available package with its version, dependencies and file lists. It then combines that data with the RPM database of installed packages.
The resolution step uses libsolv, a SAT-based dependency solver. DNF translates the request, such as installing one package, into logical constraints and asks the solver for a consistent set of packages. This approach finds solutions reliably and explains conflicts precisely when no solution exists.
The table shows the stages of a typical transaction and what can fail at each one.
| Stage | What happens | Typical failure |
|---|---|---|
| Metadata refresh | Repodata downloaded and cached | Unreachable mirror or expired metadata |
| Dependency solving | libsolv computes the package set | Conflicting or missing dependencies |
| Download | Packages fetched in parallel | Checksum mismatch or network error |
| GPG verification | Signatures checked against imported keys | Unknown or untrusted key |
| RPM transaction | Files installed and scriptlets run | File conflicts or failing scriptlet |
Each completed operation is recorded in the transaction history. dnf history lists past transactions, and dnf history undo <id> attempts to reverse one, provided the older package versions are still available in the repositories.
Essential DNF commands
DNF commands follow a verb and target pattern, and most accept package names, globs, file paths or capabilities. The following table summarizes the commands used in daily administration.
| Command | Purpose | Note |
|---|---|---|
| dnf install pkg | Install a package and its dependencies | Accepts local RPM files |
| dnf upgrade | Update all installed packages | Same as the older update verb |
| dnf remove pkg | Remove a package | Unneeded dependencies removed by default |
| dnf search term | Search names and summaries | Uses cached metadata |
| dnf provides path | Find which package supplies a file | Useful for missing commands |
| dnf repoquery | Query metadata in detail | Reverse dependencies with –whatrequires |
| dnf history | List and undo transactions | Rollback is not always possible |
Useful global options include -y for unattended confirmation, --refresh to force a metadata update, --enablerepo and --disablerepo for one-off repository changes, and --security to restrict upgrades to security advisories on distributions that publish advisory metadata.
Repositories, modules and configuration
DNF reads its main settings from /etc/dnf/dnf.conf and repository definitions from .repo files in /etc/yum.repos.d. Each repository section declares a base URL or mirror list, whether it is enabled, and whether GPG checking is required.
| Option | Where | Meaning |
|---|---|---|
| gpgcheck | Repository file | Verify package signatures, normally 1 |
| installonly_limit | dnf.conf | Number of kernels kept, default 3 |
| max_parallel_downloads | dnf.conf | Concurrent downloads, default 3, up to 20 |
| metadata_expire | Repository or dnf.conf | Age after which metadata is refreshed |
| exclude | Repository or dnf.conf | Packages DNF must never touch |
| best | dnf.conf | Require the newest version or fail |
Enterprise distributions also used modularity, which offered several streams of one software stack, such as different language runtime versions, from the same repository. Modularity was removed from Fedora and is deprecated in newer enterprise releases, so new deployments should not depend on it.
DNF compared with other package managers
DNF belongs to the family of front-end package managers that resolve dependencies and talk to repositories. Its closest neighbors in Linux package management are compared below.
| Tool | Level | Package format | Main distributions |
|---|---|---|---|
| DNF | High-level | RPM | Fedora, RHEL, Rocky, AlmaLinux |
| RPM | Low-level | RPM | Same family; no repository resolution |
| APT | High-level | deb | Debian, Ubuntu |
| dpkg | Low-level | deb | Debian family |
| Pacman | Combined | pkg.tar.zst | Arch Linux |
The DNF and RPM split mirrors the APT and dpkg split: the low-level tool installs a single file it is given, while the high-level tool decides which files are needed and where to get them. Installing RPM files directly with rpm -i bypasses dependency resolution and is best reserved for diagnostics and special cases.
Common pitfalls with DNF
Most DNF problems come from repository mixing and interrupted transactions, not from the tool itself. The points below cover the mistakes that appear most often.
- Mixing third-party repositories that ship the same packages causes conflicts; repository priorities or excludes prevent this.
- Ignoring the kernel count and setting
installonly_limittoo low can remove the only known-good kernel. - Interrupted transactions can leave duplicate packages;
dnf checkanddnf distro-synchelp repair the state. - Disabling gpgcheck to silence an error removes the main protection against tampered packages.
- Running major release upgrades with plain dnf upgrade skips the supported system-upgrade workflow.
A non-technical view
Think of DNF as a very organized shop assistant for software. You ask for one program. The assistant knows exactly which other parts that program needs. It fetches all of them from trusted warehouses and checks that nothing was tampered with on the way.
It also keeps a written record of every purchase. You can later see what was added or removed and often return to the previous state. That is why administrators on Fedora and Red Hat style systems use it for almost every software change.
A concrete example
A systems team maintains forty Rocky Linux servers and must apply security fixes every week without unplanned feature changes. A full upgrade could bring new minor versions of software that the applications have not been tested with.
The team runs dnf updateinfo list --security to review pending advisories and then dnf upgrade --security -y to install only security-related updates. A database client library is pinned with an exclude line in dnf.conf, because the application vendor certifies only one version.
When one patched package later causes a logging regression, the team identifies the transaction with dnf history and reverses it with dnf history undo. The rollback takes a few minutes, and the fix is reapplied once an updated package arrives.