Welcome to the DNF5 package manager introduction guide. In this detailed guide, we will explain what DNF5 is, how it differs from the older DNF (dnf vs. dnf5), and the significant improvements DNF5 brings to Fedora, RHEL and other RPM-based systems.
We will also cover the evolution of package management in Fedora, the reasons for adopting DNF5, and the changes in commands and configurations.
At the end, you will understand everything you need to know about DNF5, Fedora's next-generation package manager.
Table of Contents
The Evolution of Package Management in Fedora
Fedora Linux is a popular and modern Linux operating system that evolves rapidly with each new release.
Over the years, Fedora has used different package managers to manage software, starting with YUM, then DNF, and now DNF5.
1. YUM (Yellowdog Updater, Modified)
YUM is a command-line tool used to manage software on RPM-based Linux systems like Fedora, CentOS, and Red Hat. This was the predecessor to DNF.
It helps users install, update, and remove packages by automatically handling dependencies.
YUM was built on earlier tools like up2date and aimed to make package management simpler and more reliable.
Though it's now replaced by DNF in newer systems, YUM laid the foundation for modern package management in the RPM ecosystem.
2. DNF (Dandified YUM)
Introduced in Fedora 18, DNF was designed to replace the older YUM package manager.
DNF, also known as DNF4, aimed to overcome several limitations of YUM, such as performance bottlenecks, dependency resolution inefficiencies, and codebase complexity.
It served as the default package manager in Fedora for over a decade.
3. DNF5
This is the next updated version of the DNF package manager, developed as a complete rewrite of DNF.
DNF5 was developed to modernise package management in Fedora and address the shortcomings of DNF.
DNF5 is being developed and maintained by the Red Hat’s Software Management team, along with many community members around the world.
Recommended Read: Yum Extender NG: A Graphical Front-end Tool For DNF5/DNF/YUM
What is DNF5 Package Manager?
DNF5 is the next-generation RPM package manager, designed to replace the legacy DNF tool with a faster, lighter, and more intuitive solution.
Unlike the older DNF, which was primarily written in Python, DNF5 is developed in C++ for better performance and lower resource usage.
It resolves long-standing issues in package management, including slow performance, complex dependency handling, and inconsistent user experiences.
DNF5 has been available since Fedora 38. As of Fedora 41, DNF5 is the default package manager for installing, updating, and managing software on the system.
Key Features in DNF5
DNF5 brings significant improvements over the older DNF version. These include:
- Faster package transactions and optimised speed with an overhauled backend.
- Much quicker loading of repositories.
- Faster RPM queries.
- Improved memory efficiency and reduced resource consumption.
- A unified architecture that combines components, simplifying the codebase and enhancing reliability.
- An improved algorithm for faster and more accurate dependency resolution.
- Enhanced modularity and repository management, with better handling of modular repositories.
- A streamlined and unified CLI (Command Line Interface) with intuitive commands and better error messages.
- An updated terminal output.
- A revamped plugin system making it easier to create and integrate new plugins.
- Enhanced transaction history tracking.
- A New Daemon that provides an alternative to PackageKit.
- A New Core library (libdnf5).
- Fully integrated modularity.
- And many.
Why DNF5? Understanding Fedora’s Next-Gen Package Manager
The recent Fedora distributions have adopted DNF5 as default package manager, because it offers many other improvements that go beyond just speed.
DNF5 is Fast
The DNF5 package manager makes system management faster, simpler, and more consistent. It uses less system memory and offers a cleaner, more unified way to manage software.
Thanks to its C++ code base and better internal design, DNF5 works faster. These changes speed up many tasks, like reading repository data, checking for updates, and searching for packages.
It also handles RPM queries faster, even when searches ignore case. DNF5 improves how it tracks and stores transactions, which helps boost speed as well.
Improved User Experience
Beyond raw performance, it also improves the user experience. Progress bars now show clearer details, and the tool gives better feedback during installs and updates. These visual upgrades help users understand what's happening in real time.
One major goal of DNF5 is to unify the user experience. Older tools, such as DNF, YUM, PackageKit, and Microdnf, often behaved differently. That made things confusing.
New Core Library
DNF5 fixes this by using a shared library, libdnf5, and common settings across all tools. Now, users can expect the same behavior whether they’re using the command line or a graphical tool.
Developers also benefit, since there's less code to maintain and fewer bugs to fix. New plugin support for both C++ and Python also means fewer repeated features.
More New Features
DNF5 brings several new features that make it easier to use. Bash completion now works better, saving time for command-line users.
You can install local RPM files directly and see detailed reports during installs, including info about install scripts.
DNF Daemon
It also introduces the DNF Daemon, a background service that can handle package tasks without slowing down your work.
Modularity
Another key change is how DNF5 handles Modularity. The old DNF had support for it, but only in some tools. That caused problems.
DNF5 fixes this by building Modularity into its core design. Now, all tools support it the same way. This makes life easier for users, developers, and system admins alike.
In short, DNF5 gives Fedora a faster, simpler, and more reliable way to manage packages. It reduces confusion, cuts down on bugs, and offers a better experience for everyone.
DNF5 vs. DNF: Key Differences and Command Changes
For users accustomed to DNF, understanding the specific differences introduced by DNF5 is important for a smooth transition.
While many basic commands work in a similar way, DNF5 is built with a design idea that prefers clear and steady ways of working. This leads to several important changes in how you write commands, choices, and how it works inside.
Command Syntax and Option Changes
DNF5 changes how you use many commands.
In DNF4, some commands worked without subcommands. In DNF5, subcommands are now required.
For example, where you could run dnf history before, you now must run dnf5 history list to see past transactions.
This change helps reduce confusion and makes errors easier to understand when you type a command incorrectly.
Some options have also been removed or renamed. The -4 and -6 options, which let you choose between IPv4 and IPv6, are gone.
Instead, you now set the IP version using the ip_resolve setting in the config file. The --obsoletes option has also been removed.
Like IP settings, its behavior is now handled in the config. The --sec-severity option has been renamed to --advisory-severities, which makes its purpose clearer.
The -v or --verbose option, which used to work almost everywhere, is not yet fully supported in DNF5. Some commands may add it later.
DNF5 also adds new options to give you more control. For example:
--allow-downgradelets you allow or block package downgrades when solving dependencies.--offlinestores transactions so you can run them later, without a network connection.--skip-unavailablelets DNF5 continue even if some packages aren't found. This prevents the whole install or update from failing.
Some commands have also changed how they behave.
The history command now expects a transaction ID by default. If you want to filter by package name, you must use --contains-pkgs.
The mark commands have new names: install is now user, and remove is now dependency.
The upgrade command has a new --minimal option but no longer supports --skip-broken, which never worked in DNF4 anyway.
Commands for working with repos have also changed. The repolist and repoinfo are now part of a repo subcommand. So you should use dnf5 repo list or dnf5 repo info.
Old command names still work for now as shortcuts.
Also, the updateinfo command is now called advisory, and you must use a subcommand with it.
All these changes reflect a clear goal: to make DNF5 more consistent and predictable.
While the stricter syntax means users need to adjust, it helps avoid mistakes and makes scripts more reliable.
Over time, this will lead to a better experience for both new users and system admins.
Configuration and Plugin Differences
DNF5 changes how it stores and handles cache and transaction data. The user cache is now in ~/.cache/libdnf5, and the system-wide cache is in /var/cache/libdnf5. This clearer separation helps keep metadata organized and easier to manage.
Several configuration options have been removed or replaced. The old strict option is gone. Instead, DNF5 uses two new options:
skip_broken— skips packages that can’t be installed because of dependency issues.skip_unavailable— skips packages that aren’t found in any enabled repository.
This change gives users better control over how errors are handled during installs and updates.
The metadata_timer_sync option is also no longer used. Now, metadata refresh is handled by a systemd timer called dnf5-makecache.timer. You can adjust this timer if you want to change how often metadata is updated.
Another change is the deltarpm setting. In DNF5, this is now set to false by default. That’s because delta RPM support isn’t yet available in DNF5.
One of the most important changes is how DNF5 handles transactions. It keeps its own database of what packages are installed or changed.
This database is separate from DNF4’s. So if you install a package using dnf, DNF5 won’t see it in the history, and the other way around too. This can lead to confusion if you switch between the two tools.
Because of this, it’s best to stick with just one tool, ideally DNF5. Mixing them can lead to missing information, errors, or unexpected results.
Fedora’s move to DNF5 is designed to be a clean break, and users should plan for a full switch to avoid problems.
DNF4 vs DNF5: Command and Option Comparison Table
The following table provides a direct comparison of common DNF4 commands/options and their DNF5 equivalents or behavioral changes:
| DNF4 Command/Option | DNF5 Equivalent/Change | Notes/Behavioral Difference |
|---|---|---|
dnf history | dnf5 history list | Subcommands are now mandatory. history only accepts transaction IDs; use --contains-pkgs for package filtering. |
dnf updateinfo | dnf5 advisory summary | updateinfo is now advisory. Subcommands like summary, list, info are mandatory. |
dnf repolist | dnf5 repo list | repolist and repoinfo are now subcommands of repo. repolist remains a compatibility alias. |
dnf groupinstall | dnf5 group install | Many group aliases (e.g., groupinfo, grouplist) are deprecated. Use explicit subcommands. |
dnf -v or --verbose | Not implemented (may be added for specific commands) | Functionality replaced by repo info for repository details. |
dnf --skip-broken | Dropped | This option had no effect in DNF4. Decisions are now based on --best or --no-best. |
dnf --all (for list/info) | Dropped (now default behavior) | --all is the default for list and info commands. |
dnf --updates (for info) | --upgrades | Option renamed for clarity. |
dnf --available (for list) | Changed behavior | DNF5 lists all available versions, not just newer ones. |
dnf -4/-6 | Dropped | Only ip_resolve configuration option is available. |
dnf --strict (config) | Deprecated, split into skip_broken, skip_unavailable | Functionality now handled by new, more precise options. |
dnf --downloaddir | Dropped | Only --destdir is used for download command. |
dnf --installroot | New behavior | Defines where configuration and variables are loaded from. |
~/.cache/dnf | ~/.cache/libdnf5 | Default user cache directory changed. |
/var/cache/dnf | /var/cache/libdnf5 | Default root cache directory changed. |
dnf installroot | dnf5 --installroot | --installroot is now a global option. |
dnf --offline | New option | Stores the transaction for offline performance. |
dnf --skip-unavailable | New option | Allows skipping packages not available in repositories. |
dnf --allow-downgrade | New option | Enables/disables dependency downgrades during transaction resolution. |
Conclusion
DNF5 marks a major step forward in Fedora’s package management. It’s faster, lighter, and more reliable thanks to its complete rewrite in C++.
But the change isn’t just about speed. DNF5 also brings a cleaner, more consistent way to manage software across the system.
Switching from DNF to DNF5 does require learning a few new habits. Commands are more explicit, and some familiar options are gone or renamed. Still, the transition is straightforward. These changes make DNF5 more predictable, especially for scripts and automated tools.
Fedora's DNF5 offers better options for handling packages, solving problems, and keeping systems secure.
If you start using DNF5 now, you’ll avoid surprises later. In our next guide, we will cover some essential DNF5 commands with practical examples.
Resource:
