On Wed, Sep 7, 2022 at 3:17 PM Josh Boyer <jwboyer@xxxxxxxxxxxxxxxxx> wrote: > > On Tue, Sep 6, 2022 at 2:29 PM Ben Cotton <bcotton@xxxxxxxxxx> wrote: > > > > https://fedoraproject.org/wiki/Changes/ReplaceDnfWithDnf5 > > > > This document represents a proposed Change. As part of the Changes > > process, proposals are publicly announced in order to receive > > community feedback. This proposal will only be implemented if approved > > by the Fedora Engineering Steering Committee. > > > > == 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 second step after > > https://fedoraproject.org/wiki/Changes/MajorUpgradeOfMicrodnf. > > > > == Owner == > > * Name: [[User:jmracek| Jaroslav Mracek]] > > * Email: jmracek@xxxxxxxxxx > > > > > > == 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), > > providing a different behavior, and not sharing a history. We can also > > expect that DNF will have only limited support from upstream. The DNF5 > > development was announced on > > [https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx/thread/NWSURJRGZAIIMNZJT244DHDPOG2PBQXZ/ > > 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 DNF5, Dnf5Daemon > > *** DNF4 plugins were not applicable for PackageKit and Microdnf (e.g. > > versionlock, subscription-manager), therefore PackageKit behaves > > differently in comparison to DNF > > Is there any analysis on how many yum3/dnf4 plugins exist outside of > the core set that the DNF team maintains? I'm curious how much of a > porting effort is required to move from yum3/dnf4 for plugin authors. > > Will there be documentation and best practices on migration for plugin > maintainers? > As a plugin author, I'd like something like this too... > > ** 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 > > Is this daemon optional depending on installation type, or will it be > running on all installations? I am assuming it is optional and > centered mostly around whatever currently needs PackageKit. > Porting PackageKit mostly requires some API documentation and examples for porting the existing DNF backend code to the new one. Some assistance from the DNF team might be needed too. We can ship a DNF5 backend alongside the DNF4 one in the upstream sources and switch backends in Fedora as needed. -- 真実はいつも一つ！/ Always, there's only one truth! _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
