DNF rebase to version 2.0.
- Name: Jan Silhan
- Name: Michal Luscon
- Name: Igor Gnatenko
- Email: firstname.lastname@example.org, email@example.com, firstname.lastname@example.org
- Release notes owner:
- Targeted release: Fedora 26
- Last updated: 2016-09-16
- Tracker bug: <will be assigned by the Wrangler>
DNF-2.0 is the next upcoming major version of DNF package manager. Unfortunately, it brings some incompatibilities with previous version of DNF (DNF-1) which were either needed to preserve compatibility with YUM CLI or where bigger redesigns were needed. A list of identified incompatible changes can be found here.
Benefit to Fedora
New major version of DNF brings many new features and bug fixes. Moreover, the support period of older versions is reaching its end.
- Proposal owners:
- complete release notes
- deliver DNF-2.0 stack to Rawhide
- Other developers:
- Owners of 3rd party DNF plugins or components depending on DNF should check and adjust their packages otherwise they may not work with DNF-2.0.
- Release engineering:
- All release engineering tools that depends on DNF should be tested against DNF-2.0.
Enduser compatibility should be preserved as much as possible. We do not expect any manual user intervention.
How To Test
- early adopters are welcomed to use this COPR repo for testing
- testing scenarios:
- anaconda installation
- upgrade from previous Fedora version
- core functionality: install, upgrade, remove, repoquery
- dnf-plugins: copr, system-upgrade, download
- third party software: mock, yumex
N/A (not a System Wide Change)
- Contingency mechanism:
- revert to DNF-1.1.x (epoch bump)
- revert to dnf-plugins-core-0.1.x (epoch bump)
- revert to dnf-plugins-extras-0.0.x (epoch bump)
- revert to dnf-plugin-system-upgrade-0.7.x (epoch bump)
- consequent rollback of already ported components
- Contingency deadline: F26 Alpha Freeze
- Blocks release? Yes
Packages that requires dnf, python3-dnf or python2-dnf in Fedora 24
|Package||DNF-2.0 compatibility patch||Status|
|anaconda-core||https://github.com/rhinstaller/anaconda/pull/763||Agreed to merge after DNF release|
|python-dnf-langpacks||Retired in Fc25|
|python3-dnf-langpacks||Retired in Fc25|
What is the down side of making a System-Wide Change?
- Packages that uses DNF API could experience some problem without dnf-2.0 compatibility patch (the API changes are mentioned above)
- Packages that uses DNF private functions could experience some problem. They have to change the code or request new API methods.
- User or packages can experience differences if options that where changed (see above) is used.
- DNF-2.0 also provides huge number of patches for reported bugs therefore some behavior is changed, or additional information or warnings is provided like if unknown option or value is in dnf.conf or .repo files it informs user but formal version just ignore it.