Fedora 46 proposal would drop DNF4 stack and modularity

Fedora developers have proposed removing the entire legacy DNF4 package-management stack from Fedora 46, completing the shift to DNF5 and enabling full retirement of modularity support.

DNF5 became the default system package manager in Fedora 41. Official modularity builds ended as a distribution feature in Fedora 39, but Fedora still parsed modular content from third-party repositories through leftover logic in the old libdnf, libmodulemd, and related tools. The proposal, owned by Fellipe Henrique, Petr Pisar, and Fedora Release Engineering, would retire dnf 4.x, microdnf, the v1 libdnf stack, its Python bindings and plugins, and libmodulemd. Package management would then rely only on DNF5, libdnf5, and dnf5 plugins.

Zbigniew Jędrzejewski-Szmek called the move long overdue. Other maintainers raised migration risks. Maxwell G noted that release-engineering scripts and pungi still depend on python3-dnf, and that rpm-ostree still uses the older libdnf C library. He argued the contingency plan (keeping the legacy packages for one more cycle if critical ports slip) should instead treat those ports as hard blockers. Miro Hrončok warned that hundreds of user and packager scripts will break, that the Python rebuild pipeline still uses the old bindings, and that Fedora should keep backwards-compatible command names such as repoquery, as it once did for yum. Adam Williamson replied that invoking the dnf subcommand is enough.

Unless the retired packages are explicitly obsoleted, upgraded systems would keep them as orphans until users remove them. Implementation still needs Fedora Engineering Steering Committee approval.