DNF5 5.4 rewrites the package manager in C++ and drops the Python dependency
Summary
The default package manager in Fedora since release 41, rewritten in C++ with the Python dependency taken out. Installing the toolchain in an empty container takes about 60 per cent less space, and queries such as repoquery run at roughly twice the old speed.
Recommend- Name
- DNF5
- Version
- 5.4
- Pricing
- Free
- Open source
- Open source
- Operating system
- Linux
- Updated
- 2026-10-04 07:09
The dnf on Fedora has quietly been given a new skeleton
On any Fedora newer than release 41, the dnf you type is most likely no longer the one written in Python. DNF5 is a rewrite of the same project in C++, and since that release it has been the default package manager, with the dnf command reduced to a link pointing at it. The project is maintained inside the rpm software management organisation and carries the second version of the general public licence, later revisions included. What makes the change worth reading about is not that a tool was rewritten, which happens constantly, but that the rewrite was aimed at the parts users feel: how much space an installation occupies, how long a command takes to start, and how quickly a query comes back.
Taking Python out saves both size and startup cost
The old dnf was built on top of Python, so every invocation had to start an interpreter and then load a pile of modules before anything useful happened. DNF5 moved that logic into compiled libraries, and the command line tool no longer depends on Python at all. According to figures in the Fedora release notes, installing the toolchain into an empty container produces something about 60 per cent smaller than before. The gains on queries are easier to feel directly: commands such as repoquery, which lists what a repository offers, run at roughly twice the old speed, and waiting for a dependency tree or a long list of arguments shrinks with them. For a task done once a month this is a detail; for something run from a script a hundred times an hour it changes what is practical.
What actually changed
Three tools became one. The old dnf, microdnf and the graphical backend each kept their own cache, so metadata was stored several times over; dnf5 and its background service now share a single copy and that redundancy is gone. Plugins ship with the main program instead of being packaged separately, which makes a version mismatch after an upgrade much less likely. Three separate interfaces, for managing packages, for handling repositories and for resolving dependencies, were folded into one component, with bindings for scripting languages generated through a single tool and a single naming style across all of them. Output and documentation were reworked as well: the transaction table says more, the verbose chatter from script fragments is redirected into a log file and filed under the package name, every command has its own manual page, and completion in the shell was extended.
Two things to watch when migrating
First, the history databases do not talk to each other. dnf and dnf5 each record transactions in their own format, so a package installed under the old tool is invisible as an event on the new side. DNF5 does try to read the old history and convert the state of the system the first time it runs a transaction, which preserves details such as whether a package was pulled in as a dependency, so that a dependency is not later mistaken for something the user chose to install and quietly kept. Second, the enterprise distributions still run the old tool: the ninth generation of the commercial one, its two community rebuilds, and the tenth all default to dnf as before, and DNF5 has not yet taken over there. As of September 2026 the current release is 5.4. For an ordinary Fedora user, typing dnf is enough; writing dnf5 makes the distinction explicit.
To keep the cost of migrating low, compatible aliases were kept for the common commands and options, so habits carry over unchanged. The two older library packages also remain on the system and can sit alongside DNF5, though it is unwise to alternate between them when changing installed software, because the state of the system is not shared between them.
Who should care
On a single desktop where software is installed now and then, the difference amounts to commands coming back slightly faster. The real beneficiaries are setups that use Fedora as a base image: one less Python runtime inside a container makes the image a size smaller, and repeatedly running repoquery on a server to take stock of what is installed turns doubled query speed into time actually saved. The value here is not a handful of extra switches; it is that a package manager moved from a scripting language to a compiled one, so that it is smaller, asks faster and no longer stores the same cache twice. Anyone on Fedora after release 41 is already using it, while the enterprise family has a while to wait.