From Fedora Project Wiki
mNo edit summary
 
(13 intermediate revisions by 8 users not shown)
Line 1: Line 1:
{{admon/important|Change dropped|This Change is dropped and a newer version now exists. Please see [https://fedoraproject.org/wiki/Changes/SwitchToDnf5 Switch to DNF5] for updated version of this change.}}
= Make DNF5 The Default =
= Make DNF5 The Default =
{{Change_Proposal_Banner}}


== Summary ==
== Summary ==
Line 11: Line 11:
This should link to your home wiki page so we know who you are.  
This should link to your home wiki page so we know who you are.  
-->
-->
* Name: [[User:jmracek| Jaroslav Mracek]], [[User:vponcova| Vendula Poncova]]
* Name: [[User:jmracek| Jaroslav Mracek]] (DNF)
<!-- Include you email address that you can be reached should people want to contact you about helping with your change, status is requested, or technical issues need to be resolved. If the change proposal is owned by a SIG, please also add a primary contact person. -->
<!-- Include you email address that you can be reached should people want to contact you about helping with your change, status is requested, or technical issues need to be resolved. If the change proposal is owned by a SIG, please also add a primary contact person. -->
* Email: jmracek@redhat.com, vponcova@redhat.com
* Email: jmracek@redhat.com
<!--- UNCOMMENT only for Changes with assigned Shepherd (by FESCo)
<!--- UNCOMMENT only for Changes with assigned Shepherd (by FESCo)
* FESCo shepherd: [[User:FASAccountName| Shehperd name]] <email address>
* FESCo shepherd: [[User:FASAccountName| Shehperd name]] <email address>
Line 19: Line 19:


== Current status ==
== Current status ==
[[Category:ChangeReadyForFesco]]
[[Category:ChangePageIncomplete]]
<!-- When your change proposal page is completed and ready for review and announcement -->
<!-- When your change proposal page is completed and ready for review and announcement -->
<!-- remove Category:ChangePageIncomplete and change it to Category:ChangeReadyForWrangler -->
<!-- remove Category:ChangePageIncomplete and change it to Category:ChangeReadyForWrangler -->
Line 29: Line 29:
<!-- [[Category:SystemWideChange]] -->
<!-- [[Category:SystemWideChange]] -->


* Targeted release: [[Releases/39 | Fedora Linux 39 ]]  
* Targeted release: [[Releases/xx | Fedora Linux xx ]]  
* Last updated: <!-- this is an automatic macro — you don't need to change this line -->  {{REVISIONYEAR}}-{{REVISIONMONTH}}-{{REVISIONDAY2}}  
* Last updated: <!-- this is an automatic macro — you don't need to change this line -->  {{REVISIONYEAR}}-{{REVISIONMONTH}}-{{REVISIONDAY2}}  
<!-- After the change proposal is accepted by FESCo, tracking bug is created in Bugzilla and linked to this page  
<!-- After the change proposal is accepted by FESCo, tracking bug is created in Bugzilla and linked to this page  
Line 39: Line 39:
* [https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/KXCKAMXEPUZ2JRMGQQC4PHPH5EFJXDMA/ devel thread]
* [https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/KXCKAMXEPUZ2JRMGQQC4PHPH5EFJXDMA/ devel thread]
* FESCo issue: [https://pagure.io/fesco/issue/2870 #2870]
* FESCo issue: [https://pagure.io/fesco/issue/2870 #2870]
* Tracker bug: <will be assigned by the Wrangler>
* Tracker bug: [https://bugzilla.redhat.com/show_bug.cgi?id=2166026 #2166026]
* Release notes tracker: <will be assigned by the Wrangler>
* Release notes tracker: [https://pagure.io/fedora-docs/release-notes/issue/962 #962]


== Detailed Description ==
== Detailed Description ==
Line 67: Line 67:
== Feedback ==
== Feedback ==
<!-- Summarize the feedback from the community and address why you chose not to accept proposed alternatives. This section is optional for all change proposals but is strongly suggested. Incorporating feedback here as it is raised gives FESCo a clearer view of your proposal and leaves a good record for the future. If you get no feedback, that is useful to note in this section as well. For innovative or possibly controversial ideas, consider collecting feedback before you file the change proposal. -->
<!-- Summarize the feedback from the community and address why you chose not to accept proposed alternatives. This section is optional for all change proposals but is strongly suggested. Incorporating feedback here as it is raised gives FESCo a clearer view of your proposal and leaves a good record for the future. If you get no feedback, that is useful to note in this section as well. For innovative or possibly controversial ideas, consider collecting feedback before you file the change proposal. -->
* Anaconda fails to install ELN: Conflicting requests: dnf5 obsoletes yum [https://github.com/rpm-software-management/dnf5/pull/1309]


== Benefit to Fedora ==
== Benefit to Fedora ==
Line 100: Line 102:
*** Reduce disk and downloads requirements
*** Reduce disk and downloads requirements
*** Currently, DNF, Microdnf, and PackageKit use their own cache
*** Currently, DNF, Microdnf, and PackageKit use their own cache
*** Optional, may be not available for Fedora 39
*** Optional, may be not available for Fedora 41


* Decrease of a maintenance cost in the long term
* Decrease of a maintenance cost in the long term
Line 195: Line 197:
** https://copr.fedorainfracloud.org/coprs/rpmsoftwaremanagement/dnf5-unstable/
** https://copr.fedorainfracloud.org/coprs/rpmsoftwaremanagement/dnf5-unstable/


* The scope of the features for Fedora 39
* The scope of the features for Fedora 41
** https://github.com/rpm-software-management/dnf5/milestone/1
** https://github.com/rpm-software-management/dnf5/milestone/1
** Critical feature requested by community
** Critical feature requested by community
Line 219: Line 221:
** ansible
** ansible
*** tracking issue - https://github.com/ansible/ansible/issues/78898
*** tracking issue - https://github.com/ansible/ansible/issues/78898
** mock
*** tracking issue - https://github.com/rpm-software-management/mock/issues/894
** pungi
** pungi
** releng tools that call `dnf repoquery`
** releng tools that call `dnf repoquery`
Line 260: Line 264:


==== End Users ====
==== End Users ====
If an end user wants or needs to continue to use `dnf`, it would only require to exclude dnf5 in configuration (`/etc/dnf/dnf.conf`) prior upgrade to Fedora 39 (dnf, yum symlink will be still owned by original `dnf` and `yum` package).
If an end user wants or needs to continue to use `dnf`, it would only require to exclude dnf5 in configuration (`/etc/dnf/dnf.conf`) prior upgrade to Fedora 41 (dnf, yum symlink will be still owned by original `dnf` and `yum` package).


==== Applications that uses DNF CLI ====
==== Applications that uses DNF CLI ====
Line 272: Line 276:
Install `dnf5` package from https://copr.fedorainfracloud.org/coprs/rpmsoftwaremanagement/dnf5-unstable/:
Install `dnf5` package from https://copr.fedorainfracloud.org/coprs/rpmsoftwaremanagement/dnf5-unstable/:


`dnf copr enable rpmsoftwaremanagement/dnf5-unstable` ; `dnf install dnf5 dnf5-plugins`
<pre>dnf copr enable rpmsoftwaremanagement/dnf5-unstable ; dnf install dnf5 dnf5-plugins</pre>


or from Fedora rawhide:
or from Fedora rawhide:


`dnf install dnf5 dnf5-plugins`
<pre>dnf install dnf5 dnf5-plugins</pre>


=== Acceptance Criteria ===
=== Acceptance Criteria ===
The must be fulfilled before `Branch Fedora Linux 39 from Rawhide`
The must be fulfilled before `Branch Fedora Linux 41 from Rawhide`


Following commands using DNF5 must work correctly - according to expectation from previous Fedoras
Following commands using DNF5 must work correctly - according to expectation from previous Fedoras
Line 451: Line 455:
<!-- If you cannot complete your feature by the final development freeze, what is the backup plan?  This might be as simple as "Revert the shipped configuration".  Or it might not (e.g. rebuilding a number of dependent packages).  If you feature is not completed in time we want to assure others that other parts of Fedora will not be in jeopardy.  -->
<!-- If you cannot complete your feature by the final development freeze, what is the backup plan?  This might be as simple as "Revert the shipped configuration".  Or it might not (e.g. rebuilding a number of dependent packages).  If you feature is not completed in time we want to assure others that other parts of Fedora will not be in jeopardy.  -->
* Contingency mechanism: Removal of dnf obsolete and dnf symlink from DNF5 build if acceptance criteria (described above) will be not met
* Contingency mechanism: Removal of dnf obsolete and dnf symlink from DNF5 build if acceptance criteria (described above) will be not met
* Contingency deadline: `Branch Fedora Linux 39 from Rawhide`
* Contingency deadline: `Branch Fedora Linux 41 from Rawhide`
* Blocks release? No
* Blocks release? No


There are multiple options how to resolve issues with the proposal (describe in `Back-up options` section). The revert of the change will be also possible because both DNF5 and DNF are already present Fedora distribution and the proposal will not change it.
There are multiple options how to resolve issues with the proposal (describe in `Back-up options` section). The revert of the change will be also possible because both DNF5 and DNF are already present Fedora distribution and the proposal will not change it.


* If DNF5 will be not ready to replace DNF or if critical component will experience an unsolvable issue (non of options describe in `Back-up options` worked) with DNF5 or related issue with upgrade path then we will remove `dnf` obsolete and dnf symlink from DNF5 build. The removal must be synchronized with components that were ported to DNF5 CLI that required modification
* If DNF5 will be not ready to replace DNF or if critical component will experience an unsolvable issue (non of options describe in `Back-up options` worked) with DNF5 or related issue with upgrade path then we will remove `dnf` obsolete and dnf symlink from DNF5 build. The removal must be synchronized with components that were ported to DNF5 CLI that required modification


== Documentation ==
== Documentation ==

Latest revision as of 14:46, 17 April 2024

Change dropped
This Change is dropped and a newer version now exists. Please see Switch to DNF5 for updated version of this change.

Make DNF5 The Default

Summary

Make DNF5 the new default packaging tool. The change will replace DNF, YUM, and DNF-AUTOMATIC with the new DNF5 and new Libdnf5 library. The change will mainly impact command-line users of DNF. It is a second step after https://fedoraproject.org/wiki/Changes/MajorUpgradeOfMicrodnf.

Owner

Current status

Detailed Description

Currently the symlink /usr/bin/dnf points to /usr/bin/dnf-3 provided by python3-dnf. The change proposal is to

  • Point the symlink /usr/bin/dnf to /usr/bin/dnf5 provided by dnf5.
  • Ensure that DNF5 will be installed on the new system
  • Provide upgrade path for systems with installed DNF to DNF5

Impacted users and components

  • Commandline users and components (Significant)
    • Majority of user cases will be not affected
      • DNF symlink will work as expected
        • Syntax dnf install|upgrade|remove|reinstall|distro-sync|downgrade|download <package> will be fully functional
      • Same syntaxes for common commands and options
    • Different outputs
      • Transaction table contains the version of upgraded package - DNF4 only provided information only about obsoletes
      • Transaction table looks differently
      • Transaction summary will be different
    • Not all commands, options, or syntaxes will be supported
      • Dropping unused commands and options
      • Improve user experience by changing syntax
  • DNF API users (Minor)
    • python3-dnf, libdnf remain in distribution and installed on the system => no issue
    • DNF5 and DNF will not share module state and history => it is not recommended to manage software on the system using DNF and DNF5 at the same time

Feedback

  • Anaconda fails to install ELN: Conflicting requests: dnf5 obsoletes yum [1]

Benefit to Fedora

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), providing a different behavior, and not sharing a history and module state. We can also expect that DNF will have only limited support from upstream. The DNF5 development was announced on Fedora-Devel list in 2020.

  • Key features
    • Fully featured package manager without requirement of Python
    • DNF5 has smaller install size - 114 MB (Install size of DNF is 165 MB)
    • Significantly faster for many user cases
    • Reduction of number of software management tools in Fedora (DNF5 replaces DNF and Microdnf)
    • Optimization of download metadata
      • Optional download of filelists (configurable from config and commands)
  • Unified behavior of in the software management stack
    • Same user experience in workstation, server, containers
      • DNF, YUM, MICRODNF commands will be linked to DNF5
    • New Libdnf5 plugins (C++, Python) will be applicable to DNF5, Dnf5Daemon
      • 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
    • New alternative to PackageKit for RPMs (only RPM backend of PackageKit) when 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 dnf5 and daemon
      • Reduce disk and downloads requirements
      • Currently, DNF, Microdnf, and PackageKit use their own cache
      • Optional, may be not available for Fedora 41
  • 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

Problems related to using DNF5 and DNF in parallel for software modification

1. History in DNF and DNF5 are not shared

Transaction performed by DNF5 will be not visible to DNF using the dnf-3 history command. Transaction performed by DNF will be not visible to DNF5.

1.a. Information about installed dependencies are not propagated correctly

Packages installed by DNF as a dependency will be visible as a user-installed in DNF5 therefore autoremove command will not remove it when no other packed will require it or cannot be removed as unused dependency.

2. Modules

After implementation of dnf5 module install dnf and dnf5 cannot share the same location for storing state of modules, because dnf5 will store additional information about installed profiles (braking change). Modules enabled by DNF5 (dnf5 module enable <module>) will be not seen as enabled in DNF. Module profile installed by DNF5 will be not sees as installed in DNF. DNF will only see installed RPMs.


Scope

  • Proposal owners:
  • Obsolete dnf package by dnf5
    • python3-dnf (provider of dnf-3 binary and dnf API) will be not affected by the change
  • Modify comps groups to replace dnf or yum by dnf5
    • Required to deploy new systems with DNF5
  • DNF5 documentation

The project's github repository is here - https://github.com/rpm-software-management/dnf5/



  • 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 DNF5 will obsolete dnf, yum, and dnf-automatic. dnf and yum must be obsoleted because DNF5 will provide dnf and yum symlink. To ensure proper functionality dnf-automatic must be also obsoleted because DNF5 will store module state at the different location and format and DNF5 does not share history DB with DNF.

  • Upgrade from Fedora 38
    • dnf package will be obsoleted by DNF5, dnf command will be redirected to DNF5 (DNF5 will provide a symlink to /usr/bin/dnf)
    • Original dnf-3 binary (provided by python3-dnf) will remain on the system - all functionality of dnf will be still accessible using dnf-3 binary.
    • If present yum package will be obsoleted by DNF5, yum command will be redirected to DNF5
    • dnf-automatic will be obsoleted by new tool based on LIBDNF5
      • Requirements for a modification of the configuration for the new tool is unknown - will be determine later


The new DNF5 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 DNF5 will provide some compatible aliases of commands and options to improve adoption of the DNF5. DNF5 will provide different outputs.

Compatibility and Stability

We adopt CI from DNF for DNF5 to ensure stability, discover differences and missing functionality.

Back-up options

The current proposal is not about removal of current dnf stack packages from repositories. Original DNF binary (dnf-3, provided by python3-dnf) can be parallel installed safely with DNF5, and DNF will remain as a back-up option.

End Users

If an end user wants or needs to continue to use dnf, it would only require to exclude dnf5 in configuration (/etc/dnf/dnf.conf) prior upgrade to Fedora 41 (dnf, yum symlink will be still owned by original dnf and yum package).

Applications that uses DNF CLI

If an application will have a difficulty with DNF5 adoption (e.g. missing features), they can still use DNF CLI. They can replace dnf requirement by requirement of python3-dnf and call directly dnf-3 binary.

Applications that uses DNF or LIBDNF API

If an application will have a difficulty with DNF5 adoption (e.g. missing features), they can still use python3-dnf, libdnf, python3-hawkey, or python3-libdnf. Using dnf or libdnf libraries together do not create any conflict with DNF5 (parallel install-ability). But modifying installed software using DNF and DNF5 stack in parallel is not recommended.

How To Test

Install dnf5 package from https://copr.fedorainfracloud.org/coprs/rpmsoftwaremanagement/dnf5-unstable/:

dnf copr enable rpmsoftwaremanagement/dnf5-unstable ; dnf install dnf5 dnf5-plugins

or from Fedora rawhide:

dnf install dnf5 dnf5-plugins

Acceptance Criteria

The must be fulfilled before Branch Fedora Linux 41 from Rawhide

Following commands using DNF5 must work correctly - according to expectation from previous Fedoras

dnf|dnf5 install <package_spec_or_provide>

dnf|dnf5 upgrade <package_spec_or_provide>

dnf|dnf5 remove <package_spec_or_provide>

dnf|dnf5 distro-sync <package_spec_or_provide>

dnf|dnf5 repoquery <package_spec>

dnf|dnf5 repoquery --whatconflicts|whatenhances|whatobsoletes|whatprovides|whatrecommends|whatrequires|whatsuggests|whatsupplements <provide>

dnf|dnf5 list <package_spec>

dnf|dnf5 info <package_spec>

dnf|dnf5 makecache

dnf|dnf5 repolist

dnf|dnf5 repoinfo

How to report an issue, request a feature, ask for help, or open a discussion?

Community feedback, reporting issues or feature requests are important for DNF team to discover critical user cases and for work prioritizing.

Issues or feature request (RFE) can be reported using RedHat Bugzilla (https://bugzilla.redhat.com) for dnf5 component or on DNF5 upstream (https://github.com/rpm-software-management/dnf5/issues).

Also don't hesitate to open a discussion https://github.com/rpm-software-management/dnf5/discussions if you want to start with DNF5 adoptions, require help or have a question.


User Experience

  • Improved performance
    • Repository download (parallel download and metadata conversion)
    • Improved handling of multiple arguments
      • dnf|dnf5 repoquery $(rpm -qa) - DNF5 1.42s vs. DNF 4.06s
      • dnf|dnf5 upgrade $(rpm -qa) --assumeno - DNF5 2.57s vs. DNF 15.77s
  • Decreased download size of METADATA (by ~60%)
    • Optional download of filelists
  • Improved transaction table
    • Provide information about version of package that is going to be replaced during upgrade
    • Provide information why a dependency appeared in the transaction (Future Feature)
  • Great bash completion (better then DNF has)


Dependencies

There is a long list of dependent packages.

Dependencies owned by DNF team

  • dnf-plugins-core
    • installed plugins will remain on the system and will be functional with dnf-3 binary
    • step by step the functionality will be replaced by dnf5 or dnf5 plugins
      • download command is already implemented as a core dnf5 command
  • dnf-plugins-extras
    • installed plugins will remain on the system and will be functional with dnf-3 binary
    • porting functionality has a low priority, therefore implementation more depends on community


Dependencies requiring dnf

This a group requires the most of attention. They can break system upgrade path. These tools

a) use DNF from CLI, therefore they could be not functional (changed syntax, different outputs, absence of functionality, ...).

b) provide plugins for DNF. They will be still functional with dnf-3, but they require to change packaging to not require dnf, but python3-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

Dependencies requiring python3-dnf

a) They provide plugins for DNF. They will be still functional with dnf-3, but they require to change packaging to not require dnf, but python3-dnf.

b) They use DNF Python API. They should be not affected by the change, but it requires testing. It is strongly recommended to make a decision about porting to DNF5 API.

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

Dependencies requiring libdnf

They use LIBDNF API. They should be not affected by the change, but it requires testing. Tools that modify system software (e.g. PackageKit) can behave differently if they will be used together with DNF5 to manage the same system. It is strongly recommended to make a decision about porting to DNF5 API.

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

Dependencies requiring python3-hawkey

They use unsupported hawkey Python bindings. They should be not affected by the change, but it requires testing. It is strongly recommended to make a decision about porting to DNF5 API.

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


Contingency Plan

  • Contingency mechanism: Removal of dnf obsolete and dnf symlink from DNF5 build if acceptance criteria (described above) will be not met
  • Contingency deadline: Branch Fedora Linux 41 from Rawhide
  • Blocks release? No

There are multiple options how to resolve issues with the proposal (describe in Back-up options section). The revert of the change will be also possible because both DNF5 and DNF are already present Fedora distribution and the proposal will not change it.

  • If DNF5 will be not ready to replace DNF or if critical component will experience an unsolvable issue (non of options describe in Back-up options worked) with DNF5 or related issue with upgrade path then we will remove dnf obsolete and dnf symlink from DNF5 build. The removal must be synchronized with components that were ported to DNF5 CLI that required modification

Documentation

DNF5 documentation - https://dnf5.readthedocs.io/en/latest/

Release Notes