From Fedora Project Wiki
< Changes
No edit summary |
|||
| Line 123: | Line 123: | ||
** revert to dnf-plugins-extras-0.0.x (epoch bump) | ** revert to dnf-plugins-extras-0.0.x (epoch bump) | ||
** revert to dnf-plugin-system-upgrade-0.7.x (epoch bump) | ** revert to dnf-plugin-system-upgrade-0.7.x (epoch bump) | ||
** consequent rollback of already ported components | ** consequent rollback of already ported components in the table where the change for dnf-2.0 was needed | ||
<!-- When is the last time the contingency mechanism can be put in place? This will typically be the beta freeze. --> | <!-- When is the last time the contingency mechanism can be put in place? This will typically be the beta freeze. --> | ||
* Contingency deadline: F26 Alpha Freeze <!-- REQUIRED FOR SYSTEM WIDE CHANGES --> | * Contingency deadline: F26 Alpha Freeze <!-- REQUIRED FOR SYSTEM WIDE CHANGES --> | ||
Revision as of 12:36, 16 September 2016
DNF 2.0
Summary
DNF rebase to version 2.0.
Owner
- Name: Jan Silhan
- Name: Michal Luscon
- Name: Igor Gnatenko
- Email: jsilhan@redhat.com, mluscon@redhat.com, ignatenko@redhat.com
- Release notes owner:
Current status
- Targeted release: Fedora 26
- Last updated: 2016-09-16
- Tracker bug: <will be assigned by the Wrangler>
Detailed Description
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[1].
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.
Scope
- 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.
Upgrade/compatibility impact
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
User Experience
N/A (unaffected)
Dependencies
N/A (not a System Wide Change)
Contingency Plan
- 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 in the table where the change for dnf-2.0 was needed
- Contingency deadline: F26 Alpha Freeze
- Blocks release? Yes
Documentation
documented differences between 1.x and 2.0
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 |
| auter | Not informed | |
| calamares | Not informed | |
| copr-frontend | Not informed | |
| devassistant-core | Not informed | |
| dnf-automatic | In upstream | Compatible |
| dnf-plugin-spacewalk | Not informed | |
| dnf-plugin-subscription-manager | Not informed | |
| dnf-plugin-system-upgrade | https://github.com/rpm-software-management/dnf-plugins-extras/pull/66 | In progress |
| dnf-yum | In upstream | Compatible |
| dnfdaemon | https://github.com/timlau/dnf-daemon/pull/6 | Merged |
| etckeeper-dnf | Not informed | |
| fedora-upgrade | Not informed | |
| fontpackages-tools | Not informed | |
| freight-tools | Not informed | |
| freight-tools-agent | Not informed | |
| freight-tools-proxy | Not informed | |
| libreport-python | Not informed | |
| libreport-python3 | Not informed | |
| libtaskotron-fedora | Not informed | |
| lorax | Not informed | |
| policycoreutils-devel | Not informed | |
| python-dnf-langpacks | Retired in Fc25 | |
| python3-dnf-langpacks | Retired in Fc25 | |
| python3-dnf-plugin-system-upgrade | https://github.com/rpm-software-management/dnf-plugins-extras/pull/66 | In progress |
| rhn-client-tools | Not informed | |
| rolekit | Not informed | |
| supermin | Not informed | |
| system-config-language | Not informed |
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.