On Fedora 41 and later the `dnf` command is DNF 5, while RHEL 9 still ships dnf 4. What changes for you as an operator, and what is most likely to break?

## What DNF 5 actually is DNF 5 is not dnf 4 with more features; it is a re-implementation. Where dnf 4 was a Python program sitting on the `libdnf` and `hawkey` libraries, DNF 5 consolidates the work into a single native `libdnf5` stack with the command-line client built directly on it. The motivations were the ones you would expect from a package manager that runs on everything from a laptop to a minimal container image: less memory, faster metadata handling, one library that other tools can link against instead of several, and a story for the tiny-container case that previously required a separate cut-down tool, `microdnf`. Fedora 41 made it the default: on that release and later, `dnf` gives you DNF 5. RHEL 9 and earlier remain on dnf 4. If you operate a mixed estate, that is the practical situation you are in — the same command name driving two implementations. ## What stays the same Deliberately, most of what you type. The everyday verbs — `install`, `remove`, `upgrade`, `search`, `info`, `repoquery`, `history` — are there and mean the same things. Configuration remains `/etc/dnf/dnf.conf`, repository definitions remain `.repo` files under `/etc/yum.repos.d/` with the same keys, and the local RPM database underneath is unchanged. Transaction history is still recorded and still queryable. A person who knows dnf 4 is productive on DNF 5 within minutes, which is exactly the design goal for a tool this central. ## What breaks Three categories, in rough order of how often they bite. **Plugins.** dnf 4's plugin ecosystem is Python code against dnf 4's internals. DNF 5 has its own plugin mechanism, and a plugin only exists there if someone ported or rewrote it. Before migrating anything that depends on a plugin, check that the DNF 5 equivalent is packaged for the release you are moving to — this is the concrete pre-flight check, not a theoretical concern. **Scripts using the Python API.** Anything that does `import dnf` and drives transactions programmatically is written against dnf 4's API. libdnf5 exposes its own bindings; the code does not port by changing an import line. If you have such automation, it is a rewrite, and the cheaper answer is usually to stop using the API and shell out to the CLI with machine-readable options. **Output parsing.** Any script that greps or awks dnf's human-readable output is fragile across the change, because formatting is not a contract. This is a good moment to fix it properly: use exit statuses, use `repoquery` with a format option rather than parsing a table, and let a package-management module in your configuration-management tool do the work where one exists. ## The operator's checklist When a release flips you to DNF 5, the review worth doing is short. List the dnf plugins your automation relies on and confirm each has a DNF 5 counterpart. Grep your repositories for `import dnf` and for pipelines that parse dnf output. Re-test your unattended-update path end to end rather than assuming it survived. Confirm your `.repo` files are still doing what you expect with `dnf repolist --all`. None of that is difficult; skipping it is how a fleet discovers the change during a patch window instead of during a migration. ## Why an interviewer asks It is a low-frequency question and nobody will fail an interview for not knowing the version numbers. What it does probe usefully is whether you think about tooling migrations the way an operator should: not "do the commands still work" but "what did I build on top of this tool that assumed more than the command names". The candidate who immediately says "the CLI is fine; my scripts that parse its output and my plugins are the risk" has answered the question that was actually being asked.