Fedora 39 plans to use DNF5 by default

Fedora Linux 39 plans to use DNF5

Fedora Linux 39 plans to use DNF5 by default for better performance

The Fedora Engineering and Steering Committee (FESCo) announces that in Fedora 39 the team in charge will probably replace DNF, libdnf and dnf-automatic cwith the new DNF5 packaging tool and libdnf5 support library. DNF5 should improve the user experience and provide better performance for managing software on Fedora Linux.

DNF is a software package manager which installs, updates and removes packages in Fedora and is the successor to YUM (Yellow-Dog Updater Modified). DNF makes it easy to maintain packages by automatically checking dependencies and determining the actions required to install packages. This method eliminates the need to manually install or update the package and its dependencies using the rpm command.

Regarding the new functions of DNF5, the following stand out:

  • Full package manager without the need for Python
  • smallest system
  • Faster
  • Replaces DNF and Microdnf
  • Unified behavior across the entire software management stack
  • The new Libdnf5 plugins (C++, Python) will be applicable to DNF5 and Dnf5Daemon.
  • Shared settings
  • DNF/YUM has been developed over decades with the impact of multiple styles and naming conventions (options, settings, options, commands)
  • It can provide an alternative to PackageKit for RPM (a unique PackageKit backend) if it is built into Desktop.
  • Compatibility with Modularity and Comps group
  • Important improvements in the code base
  • Separation of system state from history database and /etc/dnf/module.d

In dnf-4, the list of installed packages by the user and the list of installed groups, as well as the list of installed packages of these groups, are calculated as an aggregation of history of transactions. In dnf5 it will be stored separately, which has multiple advantages, not the least of which is the fact that the history database will only be used for informational purposes and will not define the state of the system (it occasionally gets corrupted, etc.). The data stored in /etc/dnf/module.d is not supposed to be user writable and its format is not sufficient (information about installed packages with installed profiles is missing).

DNF5 is still in development and some features or options are not yet available. Yet there is work to be done in implementing modularity, internal data storage related to system history and status, and documentation and man pages. DNF5 can be tested from the repository with nightly upstream builds.

DNF5 will deprecate dnf, yum, dnf-automatic, yum-utils and DNF plugins (core and extras) python3-dnf and LIBDNF (libdnf, python3-hawkey) will be deprecated with fedora-obsolete-packages, plus it will provide a symlink to /usr/bin/dnf, so users will see the replacement as an update to DNF with limited but documented syntax changes. DNF5 will provide some supported command aliases and options to improve DNF5 adoption.

The change proposal sums things up as follows:

  1. The new DNF5 will significantly improve user experience and performance. This replacement is the second step in the Fedora software management stack upgrade. Without this change, there will be several software management tools (DNF5, old Microdnf, PackageKit, and DNF) based on different libraries (libdnf, libdnf5), which will provide different behavior and will not share history. It's also possible that DNF only has limited developer support. The development of DNF5 was announced on the Fedora-Devel list in 2020.
  2. DNF5 removes Python code for a smaller system, faster performance, and to replace existing DNF and microdnf tools. DNF5 also unifies the behavior of the software management stack, introduces a new daemon as an alternative to PackageKit for RPM, and should be much more capable. Expect faster performance for repository browsing, lookup operations, RPM queries, and metadata sharing.

The change proposal still needs to be approved by the Fedora Engineering and Steering Committee, but given Red Hat's involvement in DNF(5), it can be assumed that it will be approved and hopefully completed in time for the Fedora 39 cycle

Source: https://fedoraproject.org


Leave a Comment

Your email address will not be published. Required fields are marked with *

*

*

  1. Responsible for the data: Miguel Ángel Gatón
  2. Purpose of the data: Control SPAM, comment management.
  3. Legitimation: Your consent
  4. Communication of the data: The data will not be communicated to third parties except by legal obligation.
  5. Data storage: Database hosted by Occentus Networks (EU)
  6. Rights: At any time you can limit, recover and delete your information.