Changes/ReplaceDnfWithDnf5

Comments and Explanations
The page source contains comments providing guidance to fill out each section. They are invisible when viewing this page. To read it, choose the "view source" link.
Copy the source to a new page before making changes! DO NOT EDIT THIS TEMPLATE FOR YOUR CHANGE PROPOSAL.

Guidance
For details on how to fill out this form, see the documentation.

Replace DNF with DNF5

Summary

Make DNF5 the new default packaging tool. The change will replace DNF, LIBDNF, and DNF-AUTOMATIC with the new DNF5 and new Libdnf5 library. It is a consequence change after https://fedoraproject.org/wiki/Changes/MajorUpgradeOfMicrodnf.

Owner

• Name: Jaroslav Mracek
• Email: jmracek@redhat.com

Current status

• Targeted release: Fedora Linux 39
• Last updated: 2022-05-03
• FESCo issue: <will be assigned by the Wrangler>
• Tracker bug: <will be assigned by the Wrangler>
• Release notes tracker: <will be assigned by the Wrangler>

Detailed Description

The new DNF5 will provide a significant improvement in user experiences and performance. The replacement is the second step in upgrade of Fedora Software Management stack. Without the change there will be multiple software management tool (DNF5, old Microdnf, PackageKit, and DNF) based on different libraries (libdnf, libdnf5) and providing a different behavior. We can also expect that DNF will have only limited support from upstream. The DNF5 development was announced on Fedora-Devel list in 2020.

New DNF5 Features

• Fully featured package manager without requirement of Python
  • Smaller system
  • Faster
  • Replace DNF and Microdnf

• Unified behavior of in the software management stack
  • New Libdnf5 plugins (C++, Python) will be applicable to Microdnf, DnfDaemon
    • DNF4 plugins were not applicable for PackageKit and Microdnf (e.g. versionlock, subscription-manager), therefore PackageKit behaves differently in comparison to DNF
  • Shared configurations
    • In DNF4 not all configuration is honored by PackageKit and Microdnf
  • DNF/YUM was developed for decades with impact of multiple styles and naming conventions (options, configuration, options, commands)

• New Daemon
  • The new daemon can provide an alternative to PackageKit for RPMs (only one backend of PackageKit) if it will be integrated into Desktop
  • Support of Modularity and Comps group
• Performance improvement
  • Loading of repositories
  • Advisory operations
  • RPM queries
    • Name filters with a case-insensitive search (the repoquery command)
  • Smart sharing of metadata between dnf, microdnf, daemon
    • Reduce disk and downloads requirements
    • Currently, DNF, Microdnf, and PackageKit use their own cache
    • Optional, may be not available for Fedora 39

• Decrease of a maintenance cost in the long term
  • Shared plugins
  • Removal of functional duplicates

• Fully integrated Modularity in LIBDNF5 workflows
  • The Modularity is supported in DNF and LIBDNF but it is not fully integrated. Integration was not possible due to limitation of compatibility with other tools (PackageKit)
  • Fully integrated Modularity required changes in the library workflow

Major codebase improvements

• Reports in structure
  • DNF reports a lot of important information only in logs

• Removal of duplicated implementation
  • LIBDNF evolved from LIBHIF (PackageKit library) and HAWKEY (DNF library). The integration was never finished, therefore LIBDNF still contains duplicated functionality.
  • decrease of the code maintenance cost in future

• Unify Python bindings
  • Formal Libdnf provides two types of Python bindings
    • CPython (hawkey)
    • SWIG (libdnf)
  • Maintaining and communication between both bindings requires a lot of resources
  • Binding unification was not possible without breaking API compatibility

• SWIG bindings
  • With SWIG we can generate additional bindings without spending huge resources
  • Code in particular languages will be very similar to each other

• Separation of system state from history DB and /etc/dnf/module.d
  • In dnf-4 the list of userinstalled packages and list of installed groups along with the lists of packages installed from them is computed as an aggregation of transaction history. In dnf5 it will be stored separately, having multiple benefits, among them that the history database will serve for informational purposes only and will not define the state of the system (it gets corrupted occasionally etc.).
  • Data stored in /etc/dnf/module.d were not supposed to be user modifiable and their format is not sufficient (missing information about installed packages with installed profiles)
    • Content of /etc/dnf/module.d will be moved into the System State

Scope

• Proposal owners:

• Other developers:

• Release engineering: #Releng issue number

• Policies and guidelines: N/A (not needed for this Change)

• Trademark approval: N/A (not needed for this Change)

• Alignment with Objectives:

Upgrade/compatibility impact

The new Microdnf will obsolete dnf, yum, dnf-automatic, yum-utils, and DNF plugins (core and extras). python3-dnf and LIBDNF (libdnf, python3-hawkey) will be obsoleted by fedora-obsolete-packages.

Compatibility

The new Microdnf will provide a symlink to /usr/bin/dnf therefore users will see the replacement as an upgrade of DNF with limited but documented syntax changes. The new Microdnf will provide some compatible aliases of commands and options to improve adoption of the new Microdnf.

Dependencies

There is a long list of dependent packages

dnf

auter
calamares
copr-builder
cpanspec
dnf-plugin-diff
dnfdragora
etckeeper-dnf
fedora-review
fedora-upgrade
kiwi-systemdeps-core
libdnf-plugin-subscription-manager
lpf
mock
osbuild
perl-CPAN-Plugin-Sysdeps
policycoreutils-devel
rbm
subscription-manager
supermin
system-config-language

python3-dnf

anaconda-core
dnf-plugin-ovl
dnfdaemon
fedora-easy-karma
fedora-review
lorax
mock-core-configs
module-build-service
modulemd-tools
needrestart
pungi
python3-bodhi-client
python3-dnf-plugin-cow
python3-dnf-plugin-flunk_dependent_remove
python3-imgcreate
python3-libreport
retrace-server
system-config-language

libdnf

PackageKit
copr-builder
gnome-software-rpm-ostree
libdnf-plugin-subscription-manager
libdnf-plugin-swidtags
libdnf-plugin-txnupd

python3-hawkey

mock-core-configs
modulemd-tools
python3-rpmdeplint
retrace-server

Contingency Plan

• Contingency mechanism: (What to do? Who will do it?) N/A (not a System Wide Change)
• Contingency deadline: N/A (not a System Wide Change)
• Blocks release? N/A (not a System Wide Change), Yes/No

Documentation

N/A (not a System Wide Change)