Wiki - https://fedoraproject.org/wiki/Changes/RemoveModularityAndDNF4Support Discourse poll - https://discussion.fedoraproject.org/t/f46-change-proposal-remove-dnf4-stack-and-modularity-system-wide/204728/2
This is a proposed Change for Fedora Linux. This document represents a proposed Change. As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only be implemented if approved by the Fedora Engineering Steering Committee. == Summary == Remove the entire legacy DNF4 software stack—including `dnf` (version 4.x), `microdnf`, `libdnf` (v1), `python3-dnf`, `python3-hawkey`, `dnf-plugins-core`, `dnf-plugins-extras`, and `libmodulemd`—from Fedora 46. Because `libmodulemd` cannot be retired while the legacy `libdnf` v1 stack and related components import it, removing the legacy package manager stack and auditing its consumers enables the complete retirement of Modularity. System package management will rely exclusively on DNF5, `libdnf5`, and `dnf5-plugins`. == Owner == * Name: [[User:fellipeh| Fellipe Henrique]], [[User:ppisar| Petr Pisar]], [[Subprojects/ReleaseEngineering|Fedora Release Engineering / Maintainers]] * Email: [email protected], [email protected], [email protected] == Detailed Description == Official Fedora modularity builds were retired as a distribution feature in Fedora 39 (see [[Changes/RetireModularity]]). However, Fedora continued to parse and support modular content from third-party repositories due to legacy modularity logic maintained inside `libdnf` v1, `libmodulemd`, and related tooling. Removing `libmodulemd` from the distribution requires either a heavy refactoring of the deprecated `libdnf` v1 codebase or the complete retirement of the DNF4 stack, along with dropping or updating modularity-handling dependencies across the ecosystem. Given that `dnf5` replaced DNF4 as the default system package manager in Fedora 41, modifying legacy code is impractical. This proposal completes the package management modernization by removing the legacy DNF4 stack and retiring `libmodulemd` and its consumer stack. Targeting Fedora 46, this change will: # '''Retire the DNF4 & legacy tool stack:''' Remove `dnf` (v4), `microdnf`, `libdnf` (v1), `python3-dnf`, `python3-hawkey`, `dnf-plugins-core`, and `dnf-plugins-extras`. # '''Retire Modularity & `libmodulemd`:''' Drop `libmodulemd` and `python3-libmodulemd` from the distribution entirely, along with adjusting or retiring packages that depend on them. # '''Port ecosystem dependencies:''' Update or retire affected downstream packages depending on `libdnf` v1, `python3-dnf`, `libmodulemd`, and `python3-libmodulemd`. === Affected Packages & Scope Breakdown === To provide full scope transparency, the following packages are affected and must be ported (e.g., to `libdnf5`, `dnf5-plugins`, or direct RPM APIs) or retired alongside this change: ==== Direct Modularity Consumers ==== * '''Direct `libmodulemd` consumers:''' ** `createrepo_c` (remove modularity metadata processing support) ** `dnf` (retired by this change) ** `dnf5` (remove residual/optional `libmodulemd` bindings) ** `libdnf` (retired by this change) ** `module-build` (retired/dropped) ** `python-ModulemdTranslationHelpers` (retired/dropped) ** `rpm-ostree` (remove modularity metadata handling) ** `ursa-major` (retired/dropped) * '''Direct `python3-libmodulemd` consumers:''' ** `modulemd-tools` (retired/dropped) ** `pungi` (remove modularity metadata generation routines) ** `rpkg` (remove modularity build subcommand support) ==== DNF4 / `python3-dnf` / `libdnf` Reverse Dependencies ==== The following components currently depend on DNF4, `libdnf` v1, or `python3-dnf` and need to be ported to `libdnf5` / `dnf5`, or retired if deprecated: * '''Infrastructure & Build Tooling:''' `copr-rpmbuild`, `fedora-review`, `kiwi`, `livecd-tools`, `mock-core-configs`, `osbuild`, `pungi`, `python-coprtree` * '''System Management & Diagnostics:''' `etckeeper`, `fedora-easy-karma`, `fedrq`, `libreport`, `needrestart`, `retrace-server`, `subscription-manager`, `system-config-language` * '''DNF4 Plugin Family (Retire or Port to DNF5 Plugins):''' `dnf-plugin-cow`, `dnf-plugin-diff`, `dnf-plugin-flunk_dependent_remove`, `dnf-plugin-perfmetrics`, `dnf-plugins-core`, `dnf-plugins-extras` * '''Package Managers / Core Libraries (Retire / Replaced by DNF5 stack):''' `dnf`, `libdnf`, `microdnf` == Feedback == * '''Retire Modularity (Fedora 39):''' Modular builds and Module Build Service (MBS) infrastructure were decommissioned. * '''Default Package Manager Switch to DNF5 (Fedora 41):''' DNF5 successfully replaced DNF4 for `/usr/bin/dnf`. * '''Combined Removal Rationale:''' DNF maintainers and community feedback recommended unifying the removal of DNF4, `libdnf`, `dnf-plugins-*`, `microdnf`, and `libmodulemd` into a single System-Wide Change Proposal rather than spending effort decoupling `libmodulemd` from `libdnf` v1. == Benefit to Fedora == * '''Elimination of State Corruption & System Inconsistencies:''' Running DNF4 and DNF5 concurrently on the same system is explicitly discouraged. Dual usage leads to broken transaction histories, missing package install reasons, and inconsistent configuration handling (see [https://dnf5.readthedocs.io/en/latest/migrating_to_dnf5.7.html DNF5 Migration Guidance]). Removing DNF4 prevents users and legacy scripts from unintentionally triggering these conflicts. * '''Elimination of Technical Debt:''' Cleans up thousands of lines of unmaintained code across the distribution, eliminating the security and maintenance overhead of parallel package manager stacks (`libdnf` v1 and `libdnf5`). * '''Complete Retirement of Modularity:''' Strips out `libmodulemd` completely, removing dead metadata handling across remaining packaging toolchains (`createrepo_c`, `pungi`, `rpm-ostree`, `rpkg`). * '''Focused Development:''' Allows the DNF development team to focus 100% of bug fixes, features, and optimizations exclusively on `dnf5` and `libdnf5`. == Scope == * Proposal owners: ** Coordinate the orphan and retirement process for `dnf` (v4), `microdnf`, `libdnf` (v1), `python3-dnf`, `python3-hawkey`, `dnf-plugins-core`, `dnf-plugins-extras`, `libmodulemd`, and `python3-libmodulemd`. ** Coordinate with maintainers of `createrepo_c`, `dnf5`, `rpm-ostree`, `pungi`, and `rpkg` to disable or remove `libmodulemd` build options and dependencies. ** Assist maintainers of affected DNF4 reverse dependencies (`copr-rpmbuild`, `osbuild`, `kiwi`, `subscription-manager`, `libreport`, `mock-core-configs`, etc.) with porting to `libdnf5` or standard `dnf5` invocations. ** Retire dead modularity utilities no longer needed in the distribution (`module-build`, `python-ModulemdTranslationHelpers`, `ursa-major`, `modulemd-tools`). * Other developers: ** Package Maintainers & Script Authors: Update tools (`createrepo_c`, `pungi`, `rpkg`, `rpm-ostree`, `subscription-manager`, etc.) to drop `libmodulemd` and DNF4 dependencies. Update any spec files or local automation referencing `import dnf` (DNF4) or `dnf-plugins-core` to use `dnf5` / `libdnf5` alternatives. * Release engineering: [https://forge.fedoraproject.org/releng/tickets/issues #Releng issue number] <!-- REQUIRED FOR SYSTEM WIDE CHANGES --> ** Ensure compose and build tools (Koji, Pungi, Mock) rely exclusively on DNF5 / `libdnf5` native toolchains and do not emit modularity metadata. * Policies and guidelines: ** Update Packaging Guidelines and documentation to remove references to DNF4 subcommands, DNF4 macro helpers, and legacy Modularity packaging standards. * Trademark approval: N/A (not needed for this Change) * Alignment with the Fedora Strategy: ** Directly aligns with maintaining system architecture efficiency, eliminating deprecated technical debt, and maintaining core reliability. == Upgrade/compatibility impact == * Packages belonging to the DNF4 stack and legacy modularity tools will be retired from the Fedora 46 repositories. Unless explicitly obsoleted, existing installs will remain on upgraded machines as orphan packages until removed by the user. * Custom scripts explicitly targeting `/usr/bin/dnf-3`, `/usr/bin/dnf4`, `/usr/bin/microdnf`, or importing `python3-dnf` will fail and must be ported to DNF5 CLI or `libdnf5` bindings. * Standard interactive `dnf` invocations remain unchanged, as `/usr/bin/dnf` already points to DNF5. == Early Testing (Optional) == Do you require 'QA Blueprint' support? No == How To Test == # Audit repository dependencies (`dnf repoquery --whatrequires`) to verify no packages in Fedora 46 depend on `libdnf.so.2`, `python3-dnf`, `libmodulemd`, or `python3-libmodulemd`. # Perform routine system administration tasks (`dnf install`, `dnf upgrade`, `dnf remove`) to verify operations function smoothly via DNF5 without referencing DNF4 libraries. # Verify that core compose, build, and system tools (`createrepo_c`, `pungi`, `rpm-ostree`, `rpkg`, `osbuild`, `kiwi`, `subscription-manager`) build and run successfully without `libmodulemd` or `python3-dnf` installed. # Confirm that running legacy subcommands (such as `dnf module`) returns an explicit unrecognized command error from DNF5. == User Experience == Interactive terminal users will notice no difference, as DNF5 has been the default package manager since Fedora 41. System administrators or developers using legacy DNF4 Python scripts (`import dnf`), `microdnf` binaries, or `modulemd-tools` will need to update their workflows to `libdnf5` or DNF5 subcommands. == Dependencies == * `dnf5` / `libdnf5` / `dnf5-plugins` * Tools requiring updates to drop `libmodulemd`: `createrepo_c`, `pungi`, `rpm-ostree`, `rpkg` * Reverse dependencies requiring migration off DNF4/`python3-dnf`: `copr-rpmbuild`, `etckeeper`, `fedora-easy-karma`, `fedora-review`, `fedrq`, `kiwi`, `libreport`, `livecd-tools`, `mock-core-configs`, `needrestart`, `osbuild`, `python-coprtree`, `retrace-server`, `subscription-manager`, `system-config-language` * Build and compose tools (`mock`, `koji`, `pungi`) * Core administrative utilities (`ansible-core`, `cockpit`) == Contingency Plan == * Contingency mechanism: If critical infrastructure or blocking packages cannot finish migrating off `libdnf` v1 / `python3-dnf` or dropping `libmodulemd` before freeze, keep the legacy `dnf4`, `libdnf`, and `libmodulemd` packages in the repositories as standalone compatibility packages for one additional release cycle. * Contingency deadline: Beta Freeze. * Blocks release? No == Documentation == * Update system administration documentation on `docs.fedoraproject.org` to reflect the complete removal of DNF4, `microdnf`, and Modularity. * Refer developer and script authors to the official [https://dnf5.readthedocs.io/en/latest/tutorial/api-changes/index.html DNF5 API Migration Guide]. == Release Notes == Support for the legacy DNF4 stack (`dnf` 4.x, `microdnf`, `libdnf` v1, `python3-dnf`, `dnf-plugins-core`, `dnf-plugins-extras`) and Modularity (`libmodulemd`, `python3-libmodulemd`) has been completely removed in Fedora 46. All package management operations are driven exclusively by DNF5 and `libdnf5`. Custom scripts relying on `import dnf` or legacy `microdnf` calls must be updated to use DNF5 CLI or `libdnf5` Python bindings. -- Aoife Moloney Fedora Operations Architect Fedora Project Matrix: @amoloney:fedora.im IRC: amoloney -- _______________________________________________ devel-announce mailing list -- [email protected] To unsubscribe send an email to [email protected] Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/[email protected] Do not reply to spam, report it: https://forge.fedoraproject.org/infra/tickets/issues/new -- _______________________________________________ devel mailing list -- [email protected] To unsubscribe send an email to [email protected] Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/[email protected] Do not reply to spam, report it: https://forge.fedoraproject.org/infra/tickets/issues/new
