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? > ** 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. > ** 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 39 > > * 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 Do we have some statistics on the consolidated installation size of DNF5 vs. dnf4? Any performance comparisons? josh > * 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 > > == Feedback == > > > == Benefit to Fedora == > > > == Scope == > * Proposal owners: > > DNF5 is still in the development and some of the features or options > are not yet available. We still have to finish the implementation of > Modularity, storing internal data related to History and System State, > and also documentation and man pages. DNF5 can be tested from > repository with upstream nightly builds - > https://copr.fedorainfracloud.org/coprs/rpmsoftwaremanagement/dnf5-unstable/. > The project's github repository is here - > https://github.com/rpm-software-management/dnf5/ > > * Other developers: > * Release engineering: [https://pagure.io/releng/issues #Releng issue number] > > * 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`, `dnf-automatic`, `yum-utils`, > and DNF plugins (core and extras). python3-dnf and LIBDNF (`libdnf`, > `python3-hawkey`) will be obsoleted by `fedora-obsolete-packages`. > > > === Compatibility === > 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. > > == How To Test == > > Install `dnf5` package from > https://copr.fedorainfracloud.org/coprs/rpmsoftwaremanagement/dnf5-unstable/ > > > == User Experience == > > * Improved progress bars > * Improved transaction table > * Transaction progress reports including scriptlets reports > * Support of local rpm for transaction operation > * Great bash completion (better then DNF has) > * New commands and options that are only available with `DNF` > > > == Dependencies == > There is a long list of dependent packages > > === 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 > > === python3-dnf === > > 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 > > === libdnf === > > PackageKit > copr-builder > gnome-software-rpm-ostree > libdnf-plugin-subscription-manager > libdnf-plugin-swidtags > libdnf-plugin-txnupd > > === python3-hawkey === > > mock-core-configs > modulemd-tools > python3-rpmdeplint > retrace-server > > > == Contingency Plan == > * Contingency mechanism: (What to do? Who will do it?) > * Contingency deadline: > * Blocks release? > > > == Documentation == > none > > == Release Notes == > > > > -- > Ben Cotton > He / Him / His > Fedora Program Manager > Red Hat > TZ=America/Indiana/Indianapolis > _______________________________________________ > 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 _______________________________________________ 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
