Changes/Default_Package_Manager_Is_DNF
Summary
Make DNF/Yum4 the new default packaging tool in F22.
Owner
- Name: Aleš Kozumplík
- Email: kozumplik@gmail.com
- Release notes owner:
Current status
- Targeted release: Fedora 22
- Last updated: (DATE)
- Tracker bug: <will be assigned by the Wrangler>
Detailed Description
DNF was forked from Yum in January 2012 and available for experimenting in fedora since release 18. The project is now fully capable of replacing Yum in new Fedora installations. We want DNF to become the new default packaging tool in Fedora 22. This entails:
- letting system administrators (including users who routinely manage their packages using the legacy Yum) perform all common packaging operations using DNF, with no or minimal and documented change to the command syntax. (done)
- providing implementation of Anaconda backend so system can be bootstrapped completely without using legacy Yum. (done)
- providing alternative to all Yum plugins from yum-utils (ongoing)
- providing alternative to all release engineering tools (repoquery etc.) from yum-utils (ongoing)
- being ready/having the capacity to help out users with migration of their custom legacy plugins and extensions to DNF. The solid API documentation we provide is of great advantage here. (ongoing)
Benefit to Fedora
- A CLI package manager tool built on modern depsolving technology allowing for faster and less memory-intensive operation.
- Documented, solid Python API.
- C bindings for lower level libraries:
- Opposed to Yum, DNF runs in both Python 2 and Python 3.
Scope
This change is going to be completely transparent for Desktop users and up to certain details transparent for system administrators using Yum directly.
- Proposal owners: The majority of tasks on this change are completed. Some plugins and API calls still need to be added. The Anaconda payload implementation needs more testing, Fedora Test Day for this is pending.
- Other developers: We provide the paylaod implementation for Anaconda developers. Developers of other extensions and developers of plugins that are not part of yum-utils will have to update their code.
- Release engineering: Release engineering tools that are internal to the releng teams and not part of yum-utils will need modifications to migrate to the DNF API.
- Policies and guidelines: None at the moement.
Upgrade/compatibility impact
In F22 we will release DNF as dnf-1.0.0, providing yum-4.0.0 and obsoleting yum < 4.0.0. Doing F21->F22 upgrade should thus transparently replace the legacy Yum with DNF/Yum4. Data in YumDB and Yum history will be lost.
Users will still have the possibility to manually remove DNF and install the (legacy) 'yum' package.
For the set of incompatible CLI calls see DNF documentation.
How To Test
Install dnf/Yum4 and carry out your usual packaging operations.
User Experience
See above.
Dependencies
- The main depending package is Anaconda and we've ported it to use DNF as a backend.
- Plugins. Core plugins will be ported, we will provide help with porting users' custom legacy plugins.
Contingency Plan
- contingency plan: stay with Yum, release DNF as Yum4 but do not obsolete the legacy Yum. This way both projects can be installed together,
/usr/bin/yum
pointing to the legacy Yum in this case. - contingency deadline: beta freeze.
- as long as Anaconda installation, all CLI operations from Yum and the most critical plugins work, this change can ship.
Documentation
DNF Documentation Site, the package ships manual pages of course.