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@redhat.com
== 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@lists.fedoraproject.org/... 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 ** 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 ** 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
* 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 ==
On 06/09/2022 20:28, Ben Cotton wrote:
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.
Why not just update existing dnf packages to version 5?
DNF5 is completely a different component. It does not depend like microdnf on Python. DNF plugins are not compatible with DNF5. There will be changes in commands, options, outputs and so on therefore selling it as an update will be quite confusing.
On Thu, 2022-09-08 at 12:20 +0200, Jaroslav Mracek wrote:
DNF5 is completely a different component. It does not depend like microdnf on Python. DNF plugins are not compatible with DNF5. There will be changes in commands, options, outputs and so on therefore selling it as an update will be quite confusing.
Hi, the current COPR builds for early testers conflict on the libdnf5-devel package:
- package libdnf5-devel-5.0.0-20220826011404.2.g05e0c2c0.fc37.x86_64 conflicts with libdnf-devel < 5 provided by libdnf-devel-0.68.0- 1.fc37.x86_64
Is that going to be solved anyhow, or it's expected? The library/executable files can be installed in parallel, it seems, or at least those I tried, but having the devel files for both is not possible at the moment. It would be useful to not conflict the files, thus one can build on one machine for both versions, not replace the devel files constantly, if the two are supposed to live together for some time. Bye, Milan
On Thu, Sep 8, 2022 at 8:27 AM Milan Crha mcrha@redhat.com wrote:
On Thu, 2022-09-08 at 12:20 +0200, Jaroslav Mracek wrote:
DNF5 is completely a different component. It does not depend like microdnf on Python. DNF plugins are not compatible with DNF5. There will be changes in commands, options, outputs and so on therefore selling it as an update will be quite confusing.
Hi,the current COPR builds for early testers conflict on the libdnf5-devel package:
- package libdnf5-devel-5.0.0-20220826011404.2.g05e0c2c0.fc37.x86_64
conflicts with libdnf-devel < 5 provided by libdnf-devel-0.68.0- 1.fc37.x86_64
Is that going to be solved anyhow, or it's expected? The library/executable files can be installed in parallel, it seems, or at least those I tried, but having the devel files for both is not possible at the moment. It would be useful to not conflict the files, thus one can build on one machine for both versions, not replace the devel files constantly, if the two are supposed to live together for some time. Bye, Milan
And I'd like a pony. More seriously, installing parallel versions of the same development tools overn conflict due to files in /usr/include/ unless the original others thought to distribute the software in major version specific subdirectories. Not many utilities do that.
I am sorry, `libdnf-devel` and `libdnf5-devel` conflict on file level. We had a plan to remove the conflict, but community did not considered it as required, therefore we drop that plan. Also the conflict we can take as a feature. The code that would use libdnf and libdnf5 at the same time would be a nightmare.
On Tue, 2022-09-06 at 14:28 -0400, Ben Cotton wrote:
== 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]
[snip]
== 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
So, I feel like it's an issue that we have this huge list of dependencies of the current implementation, but up there under "Other developers:" in the Scope section, there is nothing.
The list of dependencies implies a fairly considerable amount of work is going to be necessary on the part of "other developers" to adapt all of these dependencies to dnf5. A lot of those dependencies are very important - they are core components of how we work on, build, and use Fedora.
I think this Change needs explicit buy-in from the maintainers of dependent packages, and a clear plan and timeline for how those packages will be ported to dnf5 such that the Change can land smoothly in F39 timeframe.
It is true, we need a cooperation with maintainers of many components, but not everything on the list is critical for transition or proposal itself. First of all we are not going to remove old DNF from the distribution. Then only DNF and DNF5 directly conflict therefore there is some room for an extension of transition period, but it depends on particular component. Components that installs content on the system has higher priority for transition then other use-cases with DNF.
On Thursday, September 8, 2022 Jaroslav Mracek wrote:
First of all we are not going to remove old DNF from the distribution.
Isn't that what
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`.
says?
Sep 8, 2022 8:45:19 AM Maxwell G via devel devel@lists.fedoraproject.org:
On Thursday, September 8, 2022 Jaroslav Mracek wrote:
First of all we are not going to remove old DNF from the distribution.
Isn't that what
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`.
says?
Sorry, I was unclear. I meant to say that those two statements appear contradictory. -- Best,
Maxwell G (@gotmax23) Pronouns: He/Him/His
On Tue, Sep 06, 2022 at 02:28:41PM -0400, Ben Cotton wrote:
supermin
Supermin requires only that:
dnf download --destdir=<DIR> [list of pkgs] [-c configfile]
works *as non-root* (or some equivalent of that command as non-root) to download the RPMs. Does dnf5 support that? Note it's especially important that it does not require special privileges.
Rich.
Such a user-case should be covered by DNF5 compatibility with DNF and maybe there will be not a requirement for any change in your code. There are changes in DNF5 but only when it provides a benefit and resolve some issues.
Jaroslav
On Tue, Sep 6, 2022 at 2:29 PM Ben Cotton bcotton@redhat.com 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@redhat.com
== 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@lists.fedoraproject.org/... 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@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
On Wed, Sep 7, 2022 at 3:17 PM Josh Boyer jwboyer@fedoraproject.org wrote:
On Tue, Sep 6, 2022 at 2:29 PM Ben Cotton bcotton@redhat.com 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@redhat.com
== 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@lists.fedoraproject.org/... 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!
On Wed, Sep 7, 2022 at 3:17 PM Josh Boyer <jwboyer(a)fedoraproject.org> wrote:
As a plugin author, I'd like something like this too...
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 work on improving documentation. There ate already tutorials. Tutorials: https://libdnf.readthedocs.io/en/dnf-5-devel/tutorial/index.html - Recently we rename the project to DNF5 therefore updated documentation is not yet available.
Jaroslav
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!
On Tue, Sep 6, 2022 at 2:29 PM Ben Cotton <bcotton(a)redhat.com> wrote:
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.
I think as an analyses can be count the list of dependencies mentioned in Dependencis section. Specially I focused there packages not maintained by DNF team. Plugins that are not in Fedora are difficult to track. The change announcement is also the way how to get information about external dependencies.
Will there be documentation and best practices on migration for plugin maintainers?
Yes, we will provide documentation and an example plugin. But we also are willing to help with the transition.
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.
DNF5 runs without a daemon. There are user-cases where daemon cannot be used.
Do we have some statistics on the consolidated installation size of DNF5 vs. dnf4?
Yes, DNF - download size 48 MB, install size 166 MB, 125 Packages Microdnf - download size 34 MB, install size 115 MB, 101 Packages Dnf5 with libmodulemd - download size 33 MB, install size 114 MB, 100 Packages
Any performance comparisons?
Yes, but take them as preliminary: dnf repoquery $(rpm -qa) - 4.06s dnf5 repoquery $(rpm -qa) - 1.42s dnf upgrade $(rpm -qa) --assumeno - 15.77s dnf5 upgrade $(rpm -qa) --assumeno - 2.57s
Jaroslav
josh
Am 06.09.22 um 20:28 schrieb Ben Cotton:
- 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
- Unify Python bindings
If it's still written in python, it will still be slow on devices like Pinephones. I was under the impression, that microdnf + libdnf was developed to counter this slowness?
best regards, Marius Schwarz
On Thu, Sep 8, 2022, at 10:13, Marius Schwarz wrote:
Am 06.09.22 um 20:28 schrieb Ben Cotton:
- Unify Python bindings
If it's still written in python, it will still be slow on devices like Pinephones. I was under the impression, that microdnf + libdnf was developed to counter this slowness?
My understanding is that dnf is written 100% in Python [0], while libdnf is written in C [1], dnf5 is written in C++ [2]. Though, to guarantee compatibility, dnf5 will have Python bindings to allow Python software to easily use dnf5 (as well as bindings for other languages such as Perl and Ruby).
[0] https://github.com/rpm-software-management/dnf [1] https://github.com/rpm-software-management/microdnf [2] https://github.com/rpm-software-management/dnf5
Correct, DNF5 will provide a library - LIBDNF5 that will provide C++ API plus bindings to various languages including Python.
Jaroslav
On Thu, 2022-09-08 at 10:13 +0200, Marius Schwarz wrote:
If it's still written in python, it will still be slow on devices like Pinephones. I was under the impression, that microdnf + libdnf was developed to counter this slowness?
best regards, Marius Schwarz
Though I don't know how it'll perform on an embedded device, I tested it in toolbox and it's MUCH faster than dnf 4.
Am 06.09.22 um 20:28 schrieb Ben Cotton:
If it's still written in python, it will still be slow on devices like Pinephones. I was under the impression, that microdnf + libdnf was developed to counter this slowness?
best regards, Marius Schwarz
No, DNF5 is not written in Python. Performance improvements are not based on dropping Python, but by better logic in code.
Jaroslav
Ben Cotton kirjoitti 6.9.2022 klo 21.28:
== 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.
== Upgrade/compatibility impact == The new DNF5 will obsolete `dnf`, `yum`, `dnf-automatic`, `yum-utils`, and DNF plugins (core and extras).d by `fedora-obsolete-packages`.
These two are the only mentions of dnf-automatic in this change. What does "replace" mean here? How does DNF5 cover dnf-automatic's use case?
Ben Cotton kirjoitti 6.9.2022 klo 21.28:
These two are the only mentions of dnf-automatic in this change. What does "replace" mean here? How does DNF5 cover dnf-automatic's use case?
This is a good question. We will replace the functionality, but it is still on our TODO list, therefore I cannot provide details right now. Jaroslav Mracek
For those who are still not convinced, here is a comparison:
$ toolbox create -d fedora -r 37 && toolbox enter $ sudo time dnf upgrade -y 26.79user 3.46system 0:49.09elapsed 61%CPU (0avgtext+0avgdata 489304maxresident)k 47400inputs+1243320outputs (266major+377843minor)pagefaults 0swaps
$ toolbox create -d fedora -r 37 && toolbox enter $ sudo dnf copr enable rpmsoftwaremanagement/dnf5-unstable $ sudo dnf install dnf5 -y $ sudo time dnf5 upgrade -y 11.55user 3.40system 0:33.98elapsed 44%CPU (0avgtext+0avgdata 199056maxresident)k 72inputs+1203072outputs (280major+191432minor)pagefaults 0swaps
DNF5 is ridiculously fast. The new text output using the C++ fmt library is also a bonus.
Tommy Nguyen wrote:
DNF5 is ridiculously fast.
It is faster, but "ridiculously"? In the metric that matters (elapsed wallclock time), your benchmark shows the update taking 30% less time.
That said, there are other features of DNF5 (no more Python, shared cache between PackageKit and CLI) that are IMHO even more interesting than the raw speed gain.
Kevin Kofler
On Wed, 2022-09-21 at 02:53 +0200, Kevin Kofler via devel wrote:
Tommy Nguyen wrote:
DNF5 is ridiculously fast.
It is faster, but "ridiculously"? In the metric that matters (elapsed wallclock time), your benchmark shows the update taking 30% less time.
That said, there are other features of DNF5 (no more Python, shared cache between PackageKit and CLI) that are IMHO even more interesting than the raw speed gain.
Would you have preferred if I used a different superlative? I still consider 30% less to be significant, especially because DNF5 processes metadata in parallel which makes things seem faster, whether perceived or real. And yes, the other improvements are good as well, but end users focus on speed. See: constant discussions about how to make DNF4 faster (including enabling fastestmirror which can make things slower) or perception that it is slower because it processes metadata at a different stage than apt for example.
On 21-09-2022 03:11, Tommy Nguyen wrote:
On Wed, 2022-09-21 at 02:53 +0200, Kevin Kofler via devel wrote:
Tommy Nguyen wrote:
DNF5 is ridiculously fast.
It is faster, but "ridiculously"? In the metric that matters (elapsed wallclock time), your benchmark shows the update taking 30% less time.
That said, there are other features of DNF5 (no more Python, shared cache between PackageKit and CLI) that are IMHO even more interesting than the raw speed gain.
Would you have preferred if I used a different superlative? I still consider 30% less to be significant, especially because DNF5 processes metadata in parallel which makes things seem faster, whether perceived or real. And yes, the other improvements are good as well, but end users focus on speed. See: constant discussions about how to make DNF4 faster (including enabling fastestmirror which can make things slower) or perception that it is slower because it processes metadata at a different stage than apt for example.
As of recent, memory usage might be of a larger concern. Of which your data shows a very welcome 40% reduction. I'll gladly take the speed improvement as a bonus.
Having followed the discussion, the challenging part will be the adaptation of all dependent packages to DNF5. I'll leave it to others to coin terms and attributes for the new DNF5.
-- Sandro
On 21-09-2022 09:33, Sandro wrote:
As of recent, memory usage might be of a larger concern. Of which your data shows a very welcome 40% reduction. I'll gladly take the speed improvement as a bonus.
I wrote that before morning coffee. It's a 60% reduction. DNF5 is using only 40% of what DNF uses in Tommy's test case.
Am 20.09.22 um 22:53 schrieb Tommy Nguyen:
DNF5 is ridiculously fast. The new text output using the C++ fmt library is also a bonus.
Yes, it's fast, which is a great improvement \o/ The new output format is ... debateable. It has advantages with "screen -x"-sessions with different resolutions, but hardcore dnf fans will need to adapt to it. The old one was a bit simplier and had a more eased, not to say relaxed, flair ;)
best regards, Marius Schwarz
Ben Cotton kirjoitti 6.9.2022 klo 21.28:
https://fedoraproject.org/wiki/Changes/ReplaceDnfWithDnf5
== 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.
== How To Test ==
Install `dnf5` package from https://copr.fedorainfracloud.org/coprs/rpmsoftwaremanagement/dnf5-unstable/
I did this, and tried using dnf5 instead of dnf. It look like dnf5 wants to switch a lot of packages I have to modules. It is my understanding that in Fedora, nothing should be installed from modules unless explictly requested. What is going on here?
Using postgresql as an example, I have it installed as regular rpm, not module:
$ LANG=C.UTF-8 dnf -C info --installed postgresql Installed Packages Name : postgresql Version : 14.3 Release : 8.fc37 Architecture : x86_64 Size : 6.0 M Source : postgresql-14.3-8.fc37.src.rpm Repository : @System From repo : fedora
But dnf5 wants to use a module instead:
$ LANG=C.UTF-8 sudo dnf5 upgrade --assumeno postgresql Updating and loading repositories: Repositories loaded. Package Arch Version Repository Upgrading: postgresql x86_64 15beta2-1.module_f37 fedora-mod replacing postgresql x86_64 14.3-8.fc37 <unknown> postgresql-private-libs x86_64 15beta2-1.module_f37 fedora-mod replacing postgresql-private-libs x86_64 14.3-8.fc37 <unknown> postgresql-server x86_64 15beta2-1.module_f37 fedora-mod replacing postgresql-server x86_64 14.3-8.fc37 <unknown> Installing dependencies: libicu69 x86_64 69.1-1.fc37 fedora
Transaction Summary: Installing: 1 packages Upgrading: 3 packages Replacing: 3 packages
Operation aborted by the user.
As far as I know DNF5 has not yet fully support modules. Probably the build of DNF5 you use still does not perform modular filtering. I believe that should change before adding DNF5 into Fedora. As a workaround, if you do not use modules, simply disable the modular repositories.
On Thu, Sep 22, 2022 at 3:59 PM Otto Liljalaakso otto.liljalaakso@iki.fi wrote:
Ben Cotton kirjoitti 6.9.2022 klo 21.28:
https://fedoraproject.org/wiki/Changes/ReplaceDnfWithDnf5
== 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.
== How To Test ==
Install `dnf5` package from https://copr.fedorainfracloud.org/coprs/rpmsoftwaremanagement/dnf5-unstable/
I did this, and tried using dnf5 instead of dnf. It look like dnf5 wants to switch a lot of packages I have to modules. It is my understanding that in Fedora, nothing should be installed from modules unless explictly requested. What is going on here?
Using postgresql as an example, I have it installed as regular rpm, not module:
$ LANG=C.UTF-8 dnf -C info --installed postgresql Installed Packages Name : postgresql Version : 14.3 Release : 8.fc37 Architecture : x86_64 Size : 6.0 M Source : postgresql-14.3-8.fc37.src.rpm Repository : @System From repo : fedora
But dnf5 wants to use a module instead:
$ LANG=C.UTF-8 sudo dnf5 upgrade --assumeno postgresql Updating and loading repositories: Repositories loaded. Package Arch Version Repository Upgrading: postgresql x86_64 15beta2-1.module_f37 fedora-mod replacing postgresql x86_64 14.3-8.fc37 <unknown> postgresql-private-libs x86_64 15beta2-1.module_f37 fedora-mod replacing postgresql-private-libs x86_64 14.3-8.fc37 <unknown> postgresql-server x86_64 15beta2-1.module_f37 fedora-mod replacing postgresql-server x86_64 14.3-8.fc37 <unknown> Installing dependencies: libicu69 x86_64 69.1-1.fc37 fedora
Transaction Summary: Installing: 1 packages Upgrading: 3 packages Replacing: 3 packages
Operation aborted by the user. _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Correct, the modular filtering is not yet implemented and this is the last blocker for rawhide release.
Jaroslav Mracek
Hi
On Fri, Sep 23, 2022 at 9:50 AM Jaroslav Mracek wrote:
Correct, the modular filtering is not yet implemented and this is the last blocker for rawhide release.
Quick notes from what I am seeing with limiting testing using the copr repo
* Performance is much better * Search seems busted, no output at all * "update" seems to have been dropped (and /usr/lib/dnf5/aliases.d/compatibility.conf didn't appear to be user configurable). update should really be kept as a compatibility alias * Install is overtly verbose
Rahul
On Tue Sep 6, 2022, Ben Cotton wrote:
== 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`.
I am worried about removing python3-dnf this early. As far as I can tell, the new Python libdnf bindings are very much not a drop in replacement. There are a fair amount of tools and scripts that depend on python3-dnf. The change proposal listed some of them, but Ansible's dnf module is notably missing. Personal user scripts (such as the one I use for Go CVE rebuilds) and some of releng's scripts will also be broken. I don't think we should proceed with removing python3-dnf until the majority of the important dependent software is ported. (To be clear, I don't consider my personal scripts to be important dependent software :).
In general, I think the "If DNF5 will be not ready to replace DNF" contingent needs to have definite criteria and the compatibility section needs to be expanded. Of course FESCo can do as they see fit, but I personally have qualms with approving a major change like this in advanced of an actual stable release and major testing, especially without a clear definition of when DNF5 is considered ready to replace DNF4.
-- Best,
Maxwell G (@gotmax23) Pronouns: He/Him/His
On Sat Sep 24, 2022, Maxwell G wrote:
On Tue Sep 6, 2022, Ben Cotton wrote:
== 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`.
I am worried about removing python3-dnf this early. As far as I can tell, the new Python libdnf bindings are very much not a drop in replacement. There are a fair amount of tools and scripts that depend on python3-dnf. The change proposal listed some of them, but Ansible's dnf module is notably missing.
I filed https://github.com/ansible/ansible/issues/78898 about Ansible's dnf module.
-- Maxwell G (@gotmax23) Pronouns: He/Him/His
On Sat, Sep 24, 2022 at 08:01:45PM -0500, Maxwell G via devel wrote:
On Tue Sep 6, 2022, Ben Cotton wrote:
== 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`.
I am worried about removing python3-dnf this early. As far as I can tell, the new Python libdnf bindings are very much not a drop in replacement. There are a fair amount of tools and scripts that depend on python3-dnf. The change proposal listed some of them, but Ansible's dnf
I'm worried about replacing it at all. I'd like to see them coexist until we can get things rewritten, but it also says their databases are separate which will possibly cause other issues so that's also likely to lead to different problems.
I took a stab at converting my test-dnf-transaction script yesterday, and the changes so far are not anywhere near compatible with dnf v4, and I didn't manage to get it working yet.
https://github.com/bcl/test-dnf-transaction/pull/1
https://github.com/rpm-software-management/dnf5/issues/66
Brian
python3-dnf is not going to be removed from Fedora 38 or 39. There is even not a conflict between dnf5 and python3-dnf. Anyway we strongly recommend to start with transition to DNF5.
Sorry for the delay in my reply here. ;(
Some questions:
- Release engineering: [https://pagure.io/releng/issues #Releng issue number]
no releng ticket? :(
releng depends on dnf4 for a LOT of scripts. We will need a lot of help moving those to dnf5 I am sure. A porting guide for the python bindings would be welcome.
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.
A document like the yum2dnf man page with every single change would be welcome. Also it would be nice if dnf5 accepted things and just warned on them... ie '--refresh' or 'list' (use repoquery I guess)...
== Dependencies == There is a long list of dependent packages
I see a big one missing: koji
We also have some applications that might use dnf python bindings (bodhi, packages, etc)
IMHO, I think it would be nice to get dnf5 reviewed and landed in Fedora as soon as you can, because then you would have a place for people to file bugs and iterate on things, but of course thats up to you.
kevin
Sorry for the delay in my reply here. ;(
Some questions:
no releng ticket? :(
releng depends on dnf4 for a LOT of scripts. We will need a lot of help moving those to dnf5 I am sure. A porting guide for the python bindings would be welcome.
In source (header files) we have replace tags that are supposed to help with porting. // @replaces dnf:dnf/base.py:method:Base().install(self, pkg_spec, reponame=None, strict=True, forms=None)
Additionally we have a plan to provide Python tutorial to make porting easy. Right now, documentation is our priority.
A document like the yum2dnf man page with every single change would be welcome. Also it would be nice if dnf5 accepted things and just warned on them... ie '--refresh' or 'list' (use repoquery I guess)...
Good suggestion and we plan to provide such a document
I see a big one missing: koji
We also have some applications that might use dnf python bindings (bodhi, packages, etc)
IMHO, I think it would be nice to get dnf5 reviewed and landed in Fedora as soon as you can, because then you would have a place for people to file bugs and iterate on things, but of course thats up to you.
The package review process for DNF5 is close to finish, therefore we expect release soon.
kevin
Jaroslav
So since I don't think the DNF5 name and especially the package name was elaborated here and my wish in package review to have the package name just `dnf` was completely ignored [1], I'll ask here.
Why `dnf5` and not `dnf` version 5. If it is not DNF and it needs different name, then please rather name it `foobar`. I think that introducing the version into name is wrong (with exception of compat packages) and I think that DNF should lead by example and not abusing the package name for version.
Vít
[1] https://bugzilla.redhat.com/show_bug.cgi?id=2120661#c14
Dne 06. 09. 22 v 20:28 Ben Cotton napsal(a):
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@redhat.com
== 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@lists.fedoraproject.org/... 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 ** 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 ** 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
- 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 ==
Dne 12. 10. 22 v 12:28 Vít Ondruch napsal(a):
So since I don't think the DNF5 name and especially the package name was elaborated here and my wish in package review to have the package name just `dnf` was completely ignored [1], I'll ask here.
Why `dnf5` and not `dnf` version 5. If it is not DNF and it needs different name, then please rather name it `foobar`. I think that introducing the version into name is wrong (with exception of compat packages) and I think that DNF should lead by example and not abusing the package name for version.
My opinion is that it should not be packaged as "dnf" until it is ready to fully replace DNFv4. And that will take some time. I think it is fine to introduce it now in Fedora as "dnf5" package. And later rename it to "dnf".
Miroslav
On Wed, 12 Oct 2022 at 09:49, Miroslav Suchý msuchy@redhat.com wrote:
Dne 12. 10. 22 v 12:28 Vít Ondruch napsal(a):
So since I don't think the DNF5 name and especially the package name was
elaborated here and my wish in package review
to have the package name just `dnf` was completely ignored [1], I'll ask
here.
Why `dnf5` and not `dnf` version 5. If it is not DNF and it needs
different name, then please rather name it `foobar`.
I think that introducing the version into name is wrong (with exception
of compat packages) and I think that DNF
should lead by example and not abusing the package name for version.
My opinion is that it should not be packaged as "dnf" until it is ready to fully replace DNFv4. And that will take some time. I think it is fine to introduce it now in Fedora as "dnf5" package. And later rename it to "dnf".
Maybe call it the Fedora Update Manager 'FUM' ?
Miroslav _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
On 10/12/22 08:59, Stephen Smoogen wrote:
Maybe call it the Fedora Update Manager 'FUM' ?
Unless we're going to call it RUM when it makes its way into RHEL, that name may not be the best choice :-)
On Wed, 12 Oct 2022 at 10:32, Kevin P. Fleming kpfleming@redhat.com wrote:
On 10/12/22 08:59, Stephen Smoogen wrote:
Maybe call it the Fedora Update Manager 'FUM' ?
Unless we're going to call it RUM when it makes its way into RHEL, that name may not be the best choice :-)
Well Red Hat shipped the Yellowdog Update Manager for 2 releases so I am sure they can go with FUM or RUM (RPM Update Manager).. I would avoid Backup Upgrade Manager though.
-- Kevin P. Fleming He/Him/His Principal Program Manager, RHEL Red Hat US/Eastern Time Zone _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
On Wed, Oct 12, 2022 at 4:47 PM Stephen Smoogen ssmoogen@redhat.com wrote:
On Wed, 12 Oct 2022 at 10:32, Kevin P. Fleming kpfleming@redhat.com wrote:
On 10/12/22 08:59, Stephen Smoogen wrote:
Maybe call it the Fedora Update Manager 'FUM' ?
Unless we're going to call it RUM when it makes its way into RHEL, that name may not be the best choice :-)
Well Red Hat shipped the Yellowdog Update Manager for 2 releases so I am sure they can go with FUM or RUM (RPM Update Manager).. I would avoid Backup Upgrade Manager though.
Ugh, acronyms, how boring. If we stay true to the abbreviation equilibristics that gave us DNF coming from DaNdiFied YUM, it's only natural to name the ApPoinTed DNF successor APT. =)
On Wed, Oct 12, 2022 at 11:15 AM Alexander Sosedkin asosedkin@redhat.com wrote:
On Wed, Oct 12, 2022 at 4:47 PM Stephen Smoogen ssmoogen@redhat.com wrote:
On Wed, 12 Oct 2022 at 10:32, Kevin P. Fleming kpfleming@redhat.com wrote:
On 10/12/22 08:59, Stephen Smoogen wrote:
Maybe call it the Fedora Update Manager 'FUM' ?
Unless we're going to call it RUM when it makes its way into RHEL, that name may not be the best choice :-)
Well Red Hat shipped the Yellowdog Update Manager for 2 releases so I am sure they can go with FUM or RUM (RPM Update Manager).. I would avoid Backup Upgrade Manager though.
Ugh, acronyms, how boring. If we stay true to the abbreviation equilibristics that gave us DNF coming from DaNdiFied YUM, it's only natural to name the ApPoinTed DNF successor APT. =)
I think Julian Klode would kill us for that. :P
On 12-10-2022 17:19, Neal Gompa wrote:
On Wed, Oct 12, 2022 at 11:15 AM Alexander Sosedkin asosedkin@redhat.com wrote:
On Wed, Oct 12, 2022 at 4:47 PM Stephen Smoogen ssmoogen@redhat.com wrote:
On Wed, 12 Oct 2022 at 10:32, Kevin P. Fleming kpfleming@redhat.com wrote:
On 10/12/22 08:59, Stephen Smoogen wrote:
Maybe call it the Fedora Update Manager 'FUM' ?
Unless we're going to call it RUM when it makes its way into RHEL, that name may not be the best choice :-)
I like RUM. Goes well with RPM. But I'd probably symlink it to whisky.
In honor of Seth Vidal, I would also support going back to YUM.
How about YUMMER? Referring back to YUM and making all Dutch speaking users giggle.
Well Red Hat shipped the Yellowdog Update Manager for 2 releases so I am sure they can go with FUM or RUM (RPM Update Manager).. I would avoid Backup Upgrade Manager though.
Ugh, acronyms, how boring. If we stay true to the abbreviation equilibristics that gave us DNF coming from DaNdiFied YUM, it's only natural to name the ApPoinTed DNF successor APT. =)
I think Julian Klode would kill us for that. :P
How about yapt? Putting yum into apt or making apt yummie. :D
On 12-10-2022 17:20, Jonathan Wright via devel wrote:
Think about all the guides that can be found via search engines for how to do things in a given OS. If we're constantly changing the package manager/command, even if syntax is similar or identical, it's raising the bar of entry for inexperienced users.
All solvable by providing symlinks as is currently the case for yum. I still happen to type 'yum install' on a regular basis. As the saying goes: You cannot teach an old (yellow) dog new tricks.
-- Sandro
Constantly changing the name/command of the package manager seems like a huge annoyance to end users at best, and a point of discouragement at worst.
Think about all the guides that can be found via search engines for how to do things in a given OS. If we're constantly changing the package manager/command, even if syntax is similar or identical, it's raising the bar of entry for inexperienced users.
For this reason I think it makes far more sense to let "dnf5" eventually just become "dnf" even if that means some features/flags are simply dropped.
On Wed, Oct 12, 2022 at 10:15 AM Alexander Sosedkin asosedkin@redhat.com wrote:
On Wed, Oct 12, 2022 at 4:47 PM Stephen Smoogen ssmoogen@redhat.com wrote:
On Wed, 12 Oct 2022 at 10:32, Kevin P. Fleming kpfleming@redhat.com
wrote:
On 10/12/22 08:59, Stephen Smoogen wrote:
Maybe call it the Fedora Update Manager 'FUM' ?
Unless we're going to call it RUM when it makes its way into RHEL, that name may not be the best choice :-)
Well Red Hat shipped the Yellowdog Update Manager for 2 releases so I am
sure they can go with FUM or RUM (RPM Update Manager).. I would avoid Backup Upgrade Manager though.
Ugh, acronyms, how boring. If we stay true to the abbreviation equilibristics that gave us DNF coming from DaNdiFied YUM, it's only natural to name the ApPoinTed DNF successor APT. =) _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
On Wed, Oct 12, 2022 at 10:47:07AM -0400, Stephen Smoogen wrote:
On Wed, 12 Oct 2022 at 10:32, Kevin P. Fleming kpfleming@redhat.com wrote:
On 10/12/22 08:59, Stephen Smoogen wrote:
Maybe call it the Fedora Update Manager 'FUM' ?
Unless we're going to call it RUM when it makes its way into RHEL, that name may not be the best choice :-)
Well Red Hat shipped the Yellowdog Update Manager for 2 releases so I am sure they can go with FUM or RUM (RPM Update Manager).. I would avoid Backup Upgrade Manager though.
How about PUM, Package Update Manager? Pa rum pum pum pum...
On 10/12/22 17:47, Stephen Smoogen wrote:
On Wed, 12 Oct 2022 at 10:32, Kevin P. Fleming <kpfleming@redhat.com mailto:kpfleming@redhat.com> wrote:
On 10/12/22 08:59, Stephen Smoogen wrote: > Maybe call it the Fedora Update Manager 'FUM' ? Unless we're going to call it RUM when it makes its way into RHEL, that name may not be the best choice :-)Well Red Hat shipped the Yellowdog Update Manager for 2 releases so I am sure they can go with FUM or RUM (RPM Update Manager)..
RPM Update Manager, an easily pronouncable and distro agnostic acronym which even makes sense. Now that would be a hard sell...
- Panu -
On Thu, Oct 13, 2022 at 10:36:52AM +0300, Panu Matilainen wrote:
On 10/12/22 17:47, Stephen Smoogen wrote:
On Wed, 12 Oct 2022 at 10:32, Kevin P. Fleming <kpfleming@redhat.com mailto:kpfleming@redhat.com> wrote:
On 10/12/22 08:59, Stephen Smoogen wrote: > Maybe call it the Fedora Update Manager 'FUM' ? Unless we're going to call it RUM when it makes its way into RHEL, that name may not be the best choice :-)Well Red Hat shipped the Yellowdog Update Manager for 2 releases so I am sure they can go with FUM or RUM (RPM Update Manager)..
RPM Update Manager, an easily pronouncable and distro agnostic acronym which even makes sense. Now that would be a hard sell...
Depends, once the age question is resolved, buying RUM should be fairly straight forward :-p
Pierre
On Wed, Oct 12, 2022 at 10:31 AM Kevin P. Fleming kpfleming@redhat.com wrote:
On 10/12/22 08:59, Stephen Smoogen wrote:
Maybe call it the Fedora Update Manager 'FUM' ?
Unless we're going to call it RUM when it makes its way into RHEL, that name may not be the best choice :-)
Let's not forget all the other distros that now use DNF... This would be a very poor choice indeed. :)
Heh, I would really prefer to stay with "dnf", but thx everybody for brainstorming the name. I like the proposals ;)
Vít
Dne 12. 10. 22 v 15:59 Stephen Smoogen napsal(a):
On Wed, 12 Oct 2022 at 09:49, Miroslav Suchý msuchy@redhat.com wrote:
Dne 12. 10. 22 v 12:28 Vít Ondruch napsal(a): > So since I don't think the DNF5 name and especially the package name was elaborated here and my wish in package review > to have the package name just `dnf` was completely ignored [1], I'll ask here. > > Why `dnf5` and not `dnf` version 5. If it is not DNF and it needs different name, then please rather name it `foobar`. > I think that introducing the version into name is wrong (with exception of compat packages) and I think that DNF > should lead by example and not abusing the package name for version. My opinion is that it should not be packaged as "dnf" until it is ready to fully replace DNFv4. And that will take some time. I think it is fine to introduce it now in Fedora as "dnf5" package. And later rename it to "dnf".Maybe call it the Fedora Update Manager 'FUM' ?
Miroslav _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue-- Stephen Smoogen, Red Hat Automotive Let us be kind to one another, for most of us are fighting a hard battle. -- Ian MacClaren
devel mailing list --devel@lists.fedoraproject.org To unsubscribe send an email todevel-leave@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it:https://pagure.io/fedora-infrastructure/new_issue
I am sorry, DNF and DNF5 is not a Fedora packager. DNF and DNF5 is an upstream project shipped to Fedora and other distributions including OpenSuse.
Jaroslav
Dne 12. 10. 22 v 15:48 Miroslav Suchý napsal(a):
Dne 12. 10. 22 v 12:28 Vít Ondruch napsal(a):
So since I don't think the DNF5 name and especially the package name was elaborated here and my wish in package review to have the package name just `dnf` was completely ignored [1], I'll ask here.
Why `dnf5` and not `dnf` version 5. If it is not DNF and it needs different name, then please rather name it `foobar`. I think that introducing the version into name is wrong (with exception of compat packages) and I think that DNF should lead by example and not abusing the package name for version.
My opinion is that it should not be packaged as "dnf" until it is ready to fully replace DNFv4. And that will take some time. I think it is fine to introduce it now in Fedora as "dnf5" package. And later rename it to "dnf".
There are following statements in the "Scope" section of current change proposal:
* Obsolete dnf package by dnf5
* Modify comps groups to replace dnf or yum by dnf5
This does not suggest that "And later rename it to "dnf"." is the plan.
But if it is the plan, then I'd love to see it documented in the change proposal. Of course the rename back to "dnf" should happen prior various places and especially documentation gets updated to "dnf5".
Vít
Il 12/10/22 12:28, Vít Ondruch ha scritto:
So since I don't think the DNF5 name and especially the package name was elaborated here and my wish in package review to have the package name just `dnf` was completely ignored [1], I'll ask here.
Why `dnf5` and not `dnf` version 5. If it is not DNF and it needs different name, then please rather name it `foobar`. I think that introducing the version into name is wrong (with exception of compat packages) and I think that DNF should lead by example and not abusing the package name for version.
Vít
My guess is that dnf5 is an entirely different beast than dnf. dnf was written in python, dnf5 is written in C (?), so it's not just a major version upgrade.
Mattia
Dne 12. 10. 22 v 17:02 Mattia Verga via devel napsal(a):
My guess is that dnf5 is an entirely different beast than dnf. dnf was written in python, dnf5 is written in C (?), so it's not just a major version upgrade.
It is different beast for developers and author of plugins. Otherwise 1) it has configs on the same place 2) the configs values are the same 3) the command line options are almost the same.
Miroslav
Il 12/10/22 12:28, Vít Ondruch ha scritto: My guess is that dnf5 is an entirely different beast than dnf. dnf was written in python, dnf5 is written in C (?), so it's not just a major version upgrade.
Mattia
It is correct, DNF5 is a different product written in C++.
Jaroslav
Thank you for pointing this. Why DNF5 is not named as DNF and why we do not plan to name it as DNF? DNF5 is a completely new product. It replaces dnf and microdnf. DNF5 doe's the same type of work like dnf, microdnf but behavior, internals, and plugins differents. If we will name DNF as DNF5 we will create a confusion for users. From our point of view it is much better to say that DNF5 is a new product with compatibility to DNF than it is enhanced DNF. It is quite the same what happened with replacement of yum by DNF. In some distribution DNF was shipped as YUM in version 4 and it created a lot of confusions. On the other side we want to use DNF trademark, because it inherits a lot but still DNF5 is not the same as DNF. With the naming of out stack we have a lot of restriction and I will try to mention some of them: * DNF5 cannot be named as DNF because there is requirement of parallel installability in Fedora 38. * Python import of DNF5 cannot be shipped as DNF because we need to support parallel installability of Python bindings of DNF and DNF5 (same for libdnf and libdnf5 python pindings). * Naming unification of DNF5 stack - it will be quite strange to name something dnf that cannot provide dnf and so on.
Jaroslav
Dne 17. 10. 22 v 9:28 Jaroslav Mracek napsal(a):
Thank you for pointing this. Why DNF5 is not named as DNF and why we do not plan to name it as DNF? DNF5 is a completely new product. It replaces dnf and microdnf. DNF5 doe's the same type of work like dnf, microdnf but behavior, internals, and plugins differents. If we will name DNF as DNF5 we will create a confusion for users. From our point of view it is much better to say that DNF5 is a new product with compatibility to DNF than it is enhanced DNF. It is quite the same what happened with replacement of yum by DNF. In some distribution DNF was shipped as YUM in version 4 and it created a lot of confusions.
So why there is proposed the `/usr/bin/dnf` symlink? To create the confusion again?
On the other side we want to use DNF trademark, because it inherits a lot but still DNF5 is not the same as DNF. With the naming of out stack we have a lot of restriction and I will try to mention some of them:
- DNF5 cannot be named as DNF because there is requirement of parallel installability in Fedora 38.
This ^^ is self-imposed restriction. From practical POV, if DNF5 works and provides all required functionality, there is no need for parallel installability.
- Python import of DNF5 cannot be shipped as DNF because we need to support parallel installability of Python bindings of DNF and DNF5 (same for libdnf and libdnf5 python pindings).
- Naming unification of DNF5 stack - it will be quite strange to name something dnf that cannot provide dnf and so on.
I am not convinced. Your store is not consistent. On one hand, you want to provide as much compatibility as possible, but on the other hand, you does not hesitate to break the first think you can and that is the name.
Honestly, if DNF is written in Python or C++ and if there are libraries or bindings or what not is just implementation detail. I understand it matters to you, as a developer. I understand it matters to several other people maintaining some DNF plugins. But it does not matter and should not really matter to end user.
IOW if we need to update the documentation for DNF in a way that `dnf install --some-option something` does not work DNF5 and `dnf install --new-option something` must be used, that is fine. But if the change was to `dnf5 install --some-option something`, because "we keep the compatibility, the options are the same of course", then this would be ridiculous. Yes, I know "the symlink". But you want to avoid confusion as you said, then why the symlink which will create just confusion.
Vít
Jaroslav _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Dne 17. 10. 22 v 9:28 Jaroslav Mracek napsal(a):
So why there is proposed the `/usr/bin/dnf` symlink? To create the confusion again?
For Fedora 38 we cannot ship DNF binary. We also cannot provide dnf, hawkey or libdnf in Python bindings, because the those name spaces are already taken by DNF, LIBDNF and there is a requirement to keep python3-dnf around (Fedora 39). Then we want to unify brand - therefore we do not want to ship product with one name, providing different name for bindings and so on.
This ^^ is self-imposed restriction. From practical POV, if DNF5 works and provides all required functionality, there is no need for parallel installability.
Porting to DNF5 API will require some transition period even when all required functionality will be in place.
I am not convinced. Your store is not consistent. On one hand, you want to provide as much compatibility as possible, but on the other hand, you does not hesitate to break the first think you can and that is the name.
Honestly, if DNF is written in Python or C++ and if there are libraries or bindings or what not is just implementation detail. I understand it matters to you, as a developer. I understand it matters to several other people maintaining some DNF plugins. But it does not matter and should not really matter to end user.
IOW if we need to update the documentation for DNF in a way that `dnf install --some-option something` does not work DNF5 and `dnf install --new-option something` must be used, that is fine. But if the change was to `dnf5 install --some-option something`, because "we keep the compatibility, the options are the same of course", then this would be ridiculous. Yes, I know "the symlink". But you want to avoid confusion as you said, then why the symlink which will create just confusion.
DNF team has experience with replacing of YUM in Fedora and RHEL. It give us an advantage to not repeat the same mistakes. We already know that shipping DNF as YUM was not a good idea. There was a lot of confusions therefore in RHEL9 we ship DNF as DNF and not YUM. DNF provides great compatibility with YUM but anyway it was not the best move that we did. The naming is really tricky and we cannot satisfy everyone.
Jaroslav
Vít
Hi
On Tue, Oct 25, 2022 at 7:14 AM Jaroslav Mracek wrote:
DNF team has experience with replacing of YUM in Fedora and RHEL. It give us an advantage to not repeat the same mistakes. We already know that shipping DNF as YUM was not a good idea.
This response really doesn't clarify what the end result is supposed to be. Are you planning to maintain a symlink from DNF and Yum to DNF5 after the transition is complete or not?
Rahul
Hi
On Tue, Oct 25, 2022 at 7:14 AM Jaroslav Mracek wrote:
This response really doesn't clarify what the end result is supposed to be. Are you planning to maintain a symlink from DNF and Yum to DNF5 after the transition is complete or not?
Rahul
Yes, we have a plan to maintain symlinks to `/user/bin/` + ` dnf` or `microdnf` or `yum`.
Jaroslav
On 17-10-2022 09:28, Jaroslav Mracek wrote:
- Naming unification of DNF5 stack - it will be quite strange to name
something dnf that cannot provide dnf and so on.
So RUM it is then: Re-invented Update Manager.
Re-invented like the wheel and should suit all consuming parties. :)
On Monday, 17 October 2022 08.28.11 WEST Jaroslav Mracek wrote:
Thank you for pointing this. Why DNF5 is not named as DNF and why we do not plan to name it as DNF? DNF5 is a completely new product.
That is where the irony is, it is a new product but you still keep the moniker DNF in the name (even if just for now). It is a contradictory message. :-)
The funny part, at least for me, is the 5 in the name, that reminds me of rpm5. It seems that for package related issues 5 is a cursed number. :-)
Regards,
So, coming back to the steps needed for this to happen as discussed in the FESCo ticket, I think the first one is to decide how users can start testing dnf5 on "expendable" machines.
The proposal says that dnf5 can be installed in parallel with dnf. I think this doesn't highlight what things will be broken, as tools will still use dnf. Also, @zbysek asked in the FESCo ticket what data from the RPM database is shared between the two, but didn't receive a reply: say, as a user, I install dnf5 in parallel with dnf, will I be able to "dnf install foo" and then "dnf5 uninstall foo"?
For those two things I wrote above, if in the end dnf5 will be renamed back as dnf to be a drop in replacement, wouldn't be better to have dnf5 obsolete dnf starting from now? I don't think anyone is going to test it on a production machine anyway...
Mattia
So, coming back to the steps needed for this to happen as discussed in the FESCo ticket, I think the first one is to decide how users can start testing dnf5 on "expendable" machines.
The proposal says that dnf5 can be installed in parallel with dnf. I think this doesn't highlight what things will be broken, as tools will still use dnf. Also, @zbysek asked in the FESCo ticket what data from the RPM database is shared between the two, but didn't receive a reply: say, as a user, I install dnf5 in parallel with dnf, will I be able to "dnf install foo" and then "dnf5 uninstall foo"?
Thank you for pointing it out. I will provide additional information in both Fedora proposals (replacement of DNF https://fedoraproject.org/wiki/Changes/ReplaceDnfWithDnf5#Scope and microdnf https://fedoraproject.org/wiki/Changes/MajorUpgradeOfMicrodnf#Scope). Using DNF and DNF5 in parallel to manage your system is safe. Both packagers will see content modification correctly, but they will not have not additional information to performed transaction. The situation will be the sile like when you do operation using RPM directly.
For those two things I wrote above, if in the end dnf5 will be renamed back as dnf to be a drop in replacement, wouldn't be better to have dnf5 obsolete dnf starting from now? I don't think anyone is going to test it on a production machine anyway...
Mattia
There is no plan to rename DNF5 to DNF. Our team already shipped YUM as DNF and we discovered that it is not good idea. DNF5 upstream is not going to repeat the same mistake.
Jaroslav
I believe that problems related to usage of DNF and DNF5 in parallel are ecplained in following section - https://fedoraproject.org/wiki/Changes/ReplaceDnfWithDnf5#Problems_related_t...
Jaroslav
Are there going to be provided some deprecation warning in current version of DNF, should some commands or option change in DNF5? I think this would help prepare users for the changes in advance and possible make the transition smoother.
Vít
Dne 06. 09. 22 v 20:28 Ben Cotton napsal(a):
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.
Are there going to be provided some deprecation warning in current version of DNF, should some commands or option change in DNF5? I think this would help prepare users for the changes in advance and possible make the transition smoother.
Vít
Dne 06. 09. 22 v 20:28 Ben Cotton napsal(a):
We will create man page for differences between DNF and DNF5 [WIP].
Jaroslav
Dne 25. 10. 22 v 14:00 Jaroslav Mracek napsal(a):
Are there going to be provided some deprecation warning in current version of DNF, should some commands or option change in DNF5? I think this would help prepare users for the changes in advance and possible make the transition smoother.
Vít
Dne 06. 09. 22 v 20:28 Ben Cotton napsal(a):
We will create man page for differences between DNF and DNF5 [WIP].
That is nice, but honestly who reads man pages? And especially who reads man pages of SW they are not using (assuming that the manpage will be part of DNF5 and not DNF).
I understand that deprecation warning has their own issues, but if you already put some thoughts into that topic, I'd like you to elaborate more then just provide statements like above.
Vít
Jaroslav _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Dne 25. 10. 22 v 14:00 Jaroslav Mracek napsal(a):
That is nice, but honestly who reads man pages? And especially who reads man pages of SW they are not using (assuming that the manpage will be part of DNF5 and not DNF).
Thank you for very much for a good point. We already played with this topic for DNF but that game was primary focused for RHEL and required by RHEL, therefore it was delivered to Fedora after many users already accepted DNF. If you type `man yum` you will get man pages for DNF with note that ` yum - redirecting to DNF Command Reference`. I think that this kind of approach can be used also for DNF5. You can also try `yum --help` and you will see `usage: yum [options] COMMAND`. Please all of those examples requires `yum` package installed.
I understand that deprecation warning has their own issues, but if you already put some thoughts into that topic, I'd like you to elaborate more then just provide statements like above.
DNF in early versions (1.1) provided a warning when `yum` was called. It was nice and transparent way how to send a message about redirection to DNF, but we got very strong negative feedback about that, therefore we removed it. I don't think we should repeat that approach. Personally I don't feel comfortable with education of our users using warnings, because they have value at first occurrence but then they are annoying.
Vít
Jaroslav
On Wednesday, 23 November 2022 at 11:38, Jaroslav Mracek wrote: [...]
I understand that deprecation warning has their own issues, but if you already put some thoughts into that topic, I'd like you to elaborate more then just provide statements like above.
DNF in early versions (1.1) provided a warning when `yum` was called. It was nice and transparent way how to send a message about redirection to DNF, but we got very strong negative feedback about that, therefore we removed it. I don't think we should repeat that approach. Personally I don't feel comfortable with education of our users using warnings, because they have value at first occurrence but then they are annoying.
Why don't you make them one-time only, then? I.e. drop a file in user's home directory, e.g. ~/.config/dnf5/dnf-warning-displayed or something and not display the warning if the file is there.
Regards, Dominik
I've rewritten the proposal to make it clear what it is about including additional information that were unknown before. I hope that I've addressed community suggestions and remove the confusion with original proposal. Please feel free to comment the new proposal and discuss the new content of the proposal.
Thx for heads up. I assume this is the diff:
https://fedoraproject.org/w/index.php?title=Changes%2FReplaceDnfWithDnf5&...
Vít
Dne 16. 12. 22 v 12:11 Jaroslav Mracek napsal(a):
I've rewritten the proposal to make it clear what it is about including additional information that were unknown before. I hope that I've addressed community suggestions and remove the confusion with original proposal. Please feel free to comment the new proposal and discuss the new content of the proposal. _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
I am still very much against the `dnf5` package name and I have uneasy feelings reading (in my words) "`/usr/bin/dnf` symlink will change from `/usr/bin/dnf-3` to `/usr/bin/dnf5`". This name change is going to break so basic assumption such as `rpm -q dnf`. It won't really work even when `rpm -q dnf5` output was `dnf5-6.0.0-1.fc43.noarch`.
Please give Fedora DNF version 5 instead of DNF5. Please reconsider the package name, especially when the "Obsolete dnf package by dnf5" is still part of the plan. There is still time to update the proposal.
BTW it would also help if you sketched out what is the timeline and process to deprecate DNF 4.x.
Vít
Dne 19. 12. 22 v 16:24 Vít Ondruch napsal(a):
Thx for heads up. I assume this is the diff:
https://fedoraproject.org/w/index.php?title=Changes%2FReplaceDnfWithDnf5&...
Vít
Dne 16. 12. 22 v 12:11 Jaroslav Mracek napsal(a):
I've rewritten the proposal to make it clear what it is about including additional information that were unknown before. I hope that I've addressed community suggestions and remove the confusion with original proposal. Please feel free to comment the new proposal and discuss the new content of the proposal. _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
I am still very much against the `dnf5` package name and I have uneasy feelings reading (in my words) "`/usr/bin/dnf` symlink will change from `/usr/bin/dnf-3` to `/usr/bin/dnf5`". This name change is going to break so basic assumption such as `rpm -q dnf`. It won't really work even when `rpm -q dnf5` output was `dnf5-6.0.0-1.fc43.noarch`.
Please give Fedora DNF version 5 instead of DNF5. Please reconsider the package name, especially when the "Obsolete dnf package by dnf5" is still part of the plan. There is still time to update the proposal.
I am really sorry but I don't see a way how we can ship DNF5 as DNF package. The reason is quite simple. We already ship DNF5 in Fedora 38 as DNF5. In Fedora 38 we need parallel installability with DNF and we cannot rename DNF as something else. I also remember RHEL8 where we ship DNF as YUM. And DNF is very similar to YUM - both are Python based tool. Anyway in RHEL9 the same tool is shipped as DNF, because it creates a confusion. And I don't want to experience the same issue twice. I understand that the name change is always not nice, but keeping the same name for a different tool is worse.
BTW it would also help if you sketched out what is the timeline and process to deprecate DNF 4.x.
I have a plan to open a system wide change to remove DNF for Fedora 40.
Vít
Dne 19. 12. 22 v 16:24 Vít Ondruch napsal(a):
Best regards
Jaroslav Mracek
Dne 19. 12. 22 v 17:50 Jaroslav Mracek napsal(a):
I am still very much against the `dnf5` package name and I have uneasy feelings reading (in my words) "`/usr/bin/dnf` symlink will change from `/usr/bin/dnf-3` to `/usr/bin/dnf5`". This name change is going to break so basic assumption such as `rpm -q dnf`. It won't really work even when `rpm -q dnf5` output was `dnf5-6.0.0-1.fc43.noarch`.
Please give Fedora DNF version 5 instead of DNF5. Please reconsider the package name, especially when the "Obsolete dnf package by dnf5" is still part of the plan. There is still time to update the proposal.
I am really sorry but I don't see a way how we can ship DNF5 as DNF package. The reason is quite simple. We already ship DNF5 in Fedora 38 as DNF5.
Please don't use this argument. I was objecting introducing dnf5 package at the time it was reviewed:
https://bugzilla.redhat.com/show_bug.cgi?id=2120661#c14
Now the existence of dnf5 is the reason why we can't do something?
In Fedora 38 we need parallel installability with DNF and we cannot rename DNF as something else.
I don't think you focus on the right thing. Parallel installabilility is not useful for anything except testing, mainly because the history gets broken with all the side effects. I understand that the upgrade needs to break something to improve thins for the long term, so I accept this breakage. But just one time. I can't imagine using DNF and DNF5 in parallel long term for anything useful.
I also remember RHEL8 where we ship DNF as YUM. And DNF is very similar to YUM - both are Python based tool. Anyway in RHEL9 the same tool is shipped as DNF, because it creates a confusion. And I don't want to experience the same issue twice. I understand that the name change is always not nice, but keeping the same name for a different tool is worse.
I was pointing this elsewhere. But if you really learned from YUM => DNF, then you would never mentioned DNF5, but DNF version 5. There would never be dnf5-5.0.1-1.fc38 package, but dnf-5.0.1-1.fc38. It seems to me that you are saying something while doing something completely different. This is confusing to me.
BTW it would also help if you sketched out what is the timeline and process to deprecate DNF 4.x.
I have a plan to open a system wide change to remove DNF for Fedora 40.
Good to know. Thx. Please tell me that part of the plan is renaming dnf5 => dnf and I'll shut up.
Vít
On Tue, Dec 20, 2022 at 2:16 PM Vít Ondruch vondruch@redhat.com wrote:
Good to know. Thx. Please tell me that part of the plan is renaming dnf5 => dnf and I'll shut up.
I second to this. While it makes sense to temporarily introduce a parallel installable dnf5 to enable easier early testing, I think dnf5 should get renamed to dnf when it's made the default. Anything else is just super confusing.
I am really sorry, but could we start the discussion from beginning? We use many personal opinion but we provide very limited set of facts.
I will try to summary some facts related to the naming topic.
We developed a new software management tool to replace DNF, MICRODNF, DNF libraries and potentially PackageKit. As you can see it is supposed to replace multiple tools (step by step) therefore picking the right name is not easy, but `DNF` is the strongest player here.
If we will keep the name `DNF` for the new tool we will get some benefits. The documentation will stay intact, people will not get scared of the tool change. But as negative we will create incorrect impression of using the same tool, feature set or compatibility. The new tool will not provide all features, command, options from DNF. Some features will be implemented after an user request to ensure someone is still using them. It will not support old plugins and even not Python plugins - I want to say that it is a significant changes. Why I think that incorrect impression could happen. Because we get such a request from users of RHEL8 where we keep YUM brand. And YUM (DNF in background) in RHEL8 is very similar to YUM in RHEL7. To create a strong YUM compatibility layer it required additional 3 years of development after replace of YUM in Fedora 22. I understand that the name change can be confusing but we tried with DNF both approaches - ship the new tool with a different name - DNF (Fedora) and ship it as formal tool YUM (RHEL8) and from received feedback, RHEL8 approach was worse. And it is a reason why DNF is shipped as DNF in RHEL9. It required to rewrite the whole documentation from YUM to DNF but it was worth to do it.
What we learned from Fedora deployment? Don't create any warning when people keep using the old tool name - YUM.
Please if you have any example where a significantly different tool shipped with the name of the old one was successful please share it with us.
If we will ship the new tool as DNF we will loose additional feature - back up option for users that want to use original DNF in Fedora 39. As I mentioned original DNF package will remain in distribution therefore if anyone need to use the original DNF they can upgrade from Fedora 38 without replacing the DNF. They only need to exclude the new tool from transaction. With using a different name it is still not impossible, but it will require rename of original DNF package and somehow inject it into transaction - not nice from my point of view but possible.
If we will ship the new tool with a new name we will clearly highlight that it is a new tool and that it requires more attention (testing) from user side and community. On the other hand it will require to modify documentation, but it will also help to distinguish between dnf version 4 and version 5. Using the same name in documentation is a trap for user using Google. I will search how to do something in Fedora but I can get a reference for DNF-4 tool therefore it could be not functional.
Could we rename the new tool back to DNF? Yes, we could but do we want it? Or do we want to rename DNF in Fedora back to YUM? Right now we could, because DNF is feature complete, very compatible with YUM.
There is also the last fact - DNF team is responsible for the new tool and all problems related to the change is going to our direction. If there will be a complain about the new tool, or the naming we cannot blame anyone because we have rights to say no, or don't we?
Please if you have other opinion related to the proposal, please don't hesitate to share it, but please provide facts, user cases and examples or examples from other tools. If we will know the issue related with the proposed approach we could find a way how to resolve it or document the problem as known issue.
Best regards
Jaroslav
Dne 21. 12. 22 v 11:40 Jaroslav Mracek napsal(a):
I am really sorry, but could we start the discussion from beginning? We use many personal opinion but we provide very limited set of facts.
I will try to summary some facts related to the naming topic.
We developed a new software management tool to replace DNF, MICRODNF, DNF libraries and potentially PackageKit.As you can see it is supposed to replace multiple tools (step by step) therefore picking the right name is not easy, but `DNF` is the strongest player here.
If we will keep the name `DNF` for the new tool
This is where our views differ. You call it new tool, because you have probably rewrote everything, for me it is still DNF.
we will get some benefits. The documentation will stay intact, people will not get scared of the tool change. But as negative we will create incorrect impression of using the same tool, feature set or compatibility. The new tool will not provide all features, command, options from DNF. Some features will be implemented after an user request to ensure someone is still using them. It will not support old plugins and even not Python plugins - I want to say that it is a significant changes.
This is nothing extraordinary for major version. If you changed on background from Python to C++, it is probably big change for you as a developer, but for me as a user, I mostly don't care.
Why I think that incorrect impression could happen. Because we get such a request from users of RHEL8 where we keep YUM brand. And YUM (DNF in background) in RHEL8 is very similar to YUM in RHEL7. To create a strong YUM compatibility layer it required additional 3 years of development after replace of YUM in Fedora 22. I understand that the name change can be confusing but we tried with DNF both approaches - ship the new tool with a different name - DNF (Fedora) and ship it as formal tool YUM (RHEL8) and from received feedback, RHEL8 approach was worse. And it is a reason why DNF is shipped as DNF in RHEL9. It required to rewrite the whole documentation from YUM to DNF but it was worth to do it.
What we learned from Fedora deployment? Don't create any warning when people keep using the old tool name - YUM.
YUM name should have been kept, but that is history. DNF is here for a decade (wow) already, I cannot care less about YUM. Nobody in Fedora cares about YUM. Nobody in RHEL 10 will care about YUM and most people onboarding on RHEL 9 are well aware there is DNF and it is pretty compatible from user POV.
Please if you have any example where a significantly different tool shipped with the name of the old one was successful please share it with us.
You can look at the recent discussion about ImageMagic.
Gnome changes and evolves. There were quite a lot of changes on the background.
Every language changes. It does not matter if you talk about C / Python / Ruby. The languages typically don't rename just because they release new major version (but I would not use Python as a good example here, the python3 at this stage is not any better then dnf5).
If we will ship the new tool as DNF we will loose additional feature - back up option for users that want to use original DNF in Fedora 39.
Again, it is nice that you consider backup option. But backup is what backup is, i.e. tool when you have no other option. Using both at the same machine will be far from ideal. I certainly don't want to use these two in parallel, because they use separate DBs. This is important for me, because I do care about history of my computer. So if it should be broken, then I will break it once and never look back. For new installations, I cannot imagine you would suggest to have two versions of DNF installed in parallel.
From my POV, you put too much stress on the parallel / backup options. DNF 5 is either ready for prime time or not.
As I mentioned original DNF package will remain in distribution therefore if anyone need to use the original DNF they can upgrade from Fedora 38 without replacing the DNF. They only need to exclude the new tool from transaction. With using a different name it is still not impossible, but it will require rename of original DNF package and somehow inject it into transaction - not nice from my point of view but possible.
I probably don't understand. If I'd like to keep using DNF 4, then I'd excluded the update to DNF 5. But how anybody is supposed to know that instead of excluding "dnf", they should exclude "dnf5". I still don't understand this.
If we will ship the new tool with a new name we will clearly highlight that it is a new tool and that it requires more attention (testing) from user side and community.
Majors versions are what they are. They break things. Change of the (package) name breaks even more things.
On the other hand it will require to modify documentation, but it will also help to distinguish between dnf version 4 and version 5. Using the same name in documentation is a trap for user using Google. I will search how to do something in Fedora but I can get a reference for DNF-4 tool therefore it could be not functional.
I have to repeat myself, but breaking changes are nothing exceptional. Look e.g. on Fedora packaging guidelines, which have backward compatible notes. The trap is to have multiple versions of documentation, without knowing which is the most recent one. It is much better to have single documentation, which might highlight some backward incompatible changes.
Could we rename the new tool back to DNF? Yes, we could but do we want it? Or do we want to rename DNF in Fedora back to YUM?
Again, YUM is out of the question for past 10 years. I understand your team supports YUM on RHEL, but please, forget about it.
Right now we could, because DNF is feature complete, very compatible with YUM.
There is also the last fact - DNF team is responsible for the new tool and all problems related to the change is going to our direction. If there will be a complain about the new tool, or the naming we cannot blame anyone because we have rights to say no, or don't we?
Sure, while I was objecting about the name even in the review, you did what you did. I won't change the name magically back to `dnf`. Ranting here is all I have.
Let me put together a few points to sum this up:
1) DNF name is well established, keep the DNF name (and forget about YUM).
2) Keep the compatibility on reasonable level. 100% compatibility is myth (even between the tiniest updates).
3) Changes are inevitable, especially between major versions. That is why we version, right? While nobody likes them (especially breaking changes), they are accepted. Please don't be afraid to do them for good!
4) Keep the package name, so if somebody don't want to update, they can do `dnf update --exclude dnf` instead of looking for new package name to do `dnf update --exclude dnf5`
5) I certainly wont combine DNF 4 and DNF 5 on one system. I don't think any user want to combine these, unless they are desperate. Don't bet everything on this.
6) Keep only one instance of documentation, if needed, document the old behavior
7) Tooling and framework changes on background are unimportant to end users.
Vít
Please if you have other opinion related to the proposal, please don't hesitate to share it, but please provide facts, user cases and examples or examples from other tools. If we will know the issue related with the proposed approach we could find a way how to resolve it or document the problem as known issue.
Best regards
Jaroslav _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
On Wednesday, 21 December 2022 at 12:31, Vít Ondruch wrote: [...]
Let me put together a few points to sum this up:
DNF name is well established, keep the DNF name (and forget about YUM).
Keep the compatibility on reasonable level. 100% compatibility is myth
(even between the tiniest updates).
- Changes are inevitable, especially between major versions. That is why we
version, right? While nobody likes them (especially breaking changes), they are accepted. Please don't be afraid to do them for good!
- Keep the package name, so if somebody don't want to update, they can do
`dnf update --exclude dnf` instead of looking for new package name to do `dnf update --exclude dnf5`
- I certainly wont combine DNF 4 and DNF 5 on one system. I don't think any
user want to combine these, unless they are desperate. Don't bet everything on this.
- Keep only one instance of documentation, if needed, document the old
behavior
- Tooling and framework changes on background are unimportant to end users.
This is a very good summary of my opinion as well. Thanks, Vit!
Best regards, Dominik
On Wed, Dec 21, 2022 at 01:32:10PM +0100, Dominik 'Rathann' Mierzejewski wrote:
On Wednesday, 21 December 2022 at 12:31, Vít Ondruch wrote: [...]
Let me put together a few points to sum this up:
DNF name is well established, keep the DNF name (and forget about YUM).
Keep the compatibility on reasonable level. 100% compatibility is myth
(even between the tiniest updates).
- Changes are inevitable, especially between major versions. That is why we
version, right? While nobody likes them (especially breaking changes), they are accepted. Please don't be afraid to do them for good!
- Keep the package name, so if somebody don't want to update, they can do
`dnf update --exclude dnf` instead of looking for new package name to do `dnf update --exclude dnf5`
- I certainly wont combine DNF 4 and DNF 5 on one system. I don't think any
user want to combine these, unless they are desperate. Don't bet everything on this.
- Keep only one instance of documentation, if needed, document the old
behavior
- Tooling and framework changes on background are unimportant to end users.
This is a very good summary of my opinion as well. Thanks, Vit!
Is the command line tool for DNF version 5 called /usr/bin/dnf? Or will users have to learn to use "dnf5 install ..." etc? If the latter, I think it is a bad idea. Each time a new version of "ls" comes out, they don't append a new digit to the command. Users shouldn't have to learn a new command name just to upgrade to a new major version of a command. If the syntax and functionality is substantially the same, then the command name should remain the same.
If the UX (user experience) is sustantially changed such that a user would have to learn a completely new syntax in order to use it, then perhaps it would be better to rename the whole product/command to something other than DNF. For example, when we moved from initscripts/service/chkconfig to systemd, the syntax changed enough that it made sense to have a new command "systemctl" to replace the previous commands "chkconfig" and "service".
As for the RPM package name, that is less important because it doesn't really affect the UX much. Guidance here should be taken from the packaging guidelines.
https://docs.fedoraproject.org/en-US/packaging-guidelines/Naming/#multiple
Examples:
The python-sqlalchemy package occasionally has multiple versions in Fedora for backwards compatibility. The most current version of python-sqlalchemy is named python-sqlalchemy and an older supported version is python-sqlalchemy0.5. No delimiter is used in this situation.
This seems to suggest that the package name should be "dnf" for the latest version and "dnf4" for the previous version.
Dne 21. 12. 22 v 18:45 Chuck Anderson napsal(a):
On Wed, Dec 21, 2022 at 01:32:10PM +0100, Dominik 'Rathann' Mierzejewski wrote:
On Wednesday, 21 December 2022 at 12:31, Vít Ondruch wrote: [...]
Let me put together a few points to sum this up:
DNF name is well established, keep the DNF name (and forget about YUM).
Keep the compatibility on reasonable level. 100% compatibility is myth
(even between the tiniest updates).
- Changes are inevitable, especially between major versions. That is why we
version, right? While nobody likes them (especially breaking changes), they are accepted. Please don't be afraid to do them for good!
- Keep the package name, so if somebody don't want to update, they can do
`dnf update --exclude dnf` instead of looking for new package name to do `dnf update --exclude dnf5`
- I certainly wont combine DNF 4 and DNF 5 on one system. I don't think any
user want to combine these, unless they are desperate. Don't bet everything on this.
- Keep only one instance of documentation, if needed, document the old
behavior
- Tooling and framework changes on background are unimportant to end users.
This is a very good summary of my opinion as well. Thanks, Vit!
Is the command line tool for DNF version 5 called /usr/bin/dnf? Or will users have to learn to use "dnf5 install ..." etc? If the latter, I think it is a bad idea.
Luckily the former should be the case, IOW `dnf` command stays.
Vít
Each time a new version of "ls" comes out, they don't append a new digit to the command. Users shouldn't have to learn a new command name just to upgrade to a new major version of a command. If the syntax and functionality is substantially the same, then the command name should remain the same.
If the UX (user experience) is sustantially changed such that a user would have to learn a completely new syntax in order to use it, then perhaps it would be better to rename the whole product/command to something other than DNF. For example, when we moved from initscripts/service/chkconfig to systemd, the syntax changed enough that it made sense to have a new command "systemctl" to replace the previous commands "chkconfig" and "service".
As for the RPM package name, that is less important because it doesn't really affect the UX much. Guidance here should be taken from the packaging guidelines.
https://docs.fedoraproject.org/en-US/packaging-guidelines/Naming/#multiple
Examples:
The python-sqlalchemy package occasionally has multiple versions in Fedora for backwards compatibility. The most current version of python-sqlalchemy is named python-sqlalchemy and an older supported version is python-sqlalchemy0.5. No delimiter is used in this situation.This seems to suggest that the package name should be "dnf" for the latest version and "dnf4" for the previous version. _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Because the naming of the tool is upstream decision I opened a discussion https://github.com/rpm-software-management/dnf5/discussions/210. DNF and the new tool is shipped into multiple upstream therefore we have to collect feedback from multiple distribution and upstream discussion channel is the bet place for that. I asked there several question and I provided 3 basic scenarios.
``` What name (**dnf**, yum, **dnf5**, or microdnf ) we should use for package providing binary (currently DNF5)? What binary name or symlink we should use in man pages (currently DNF5) for examples? What binary name or symlink we should use in Fedora guidelines? What binary name or symlink we should use in RHEL guidelines? How we should name packages containing plugins (additional command)? ```
Best regards
Jaroslav
On 19 Dec 2022, at 16:50, Jaroslav Mracek jmracek@redhat.com wrote:
I also remember RHEL8 where we ship DNF as YUM. And DNF is very similar to YUM - both are Python based tool. Anyway in RHEL9 the same tool is shipped as DNF, because it creates a confusion. And I don't want to experience the same issue twice. I understand that the name change is always not nice, but keeping the same name for a different tool is worse.
I'm using Oracle Linux 8 at work and some older scripts use "yum" and newer scripts use "dnf" this all just works.
What is the confusion that you are trying to avoid?
The only issue that I recall from earlier in the thread is that dnf version 5 is not feature complete enough to replace dnf version 4.
Is there any database that is corrupted if dnf v4 and dnf v5 commands are mixed on a system?
Barry
Dear community, I would like to mentioned that there is last chance (about a week) to comment the updated proposal and discussion on DNF5 github before FESCO will make a decision.
Jaroslav
-
Adam Williamson -
Alexander Sosedkin -
Barry Scott -
Ben Cotton -
Brian C. Lane -
Chuck Anderson -
Dominik 'Rathann' Mierzejewski -
Fabio Alessandro Locati -
Jaroslav Mracek -
Jonathan Wright -
Josh Boyer -
José Abílio Matos -
Kalev Lember -
Kevin Fenzi -
Kevin Kofler -
Kevin P. Fleming -
Marius Schwarz -
Mattia Verga -
Maxwell G -
Milan Crha -
Miroslav Suchý -
Neal Gompa -
Nico Kadel-Garcia -
Otto Liljalaakso -
Panu Matilainen -
Petr Pisar -
Pierre-Yves Chibon -
Rahul Sundaram -
Richard W.M. Jones -
Sandro -
Stephen Smoogen -
Tommy Nguyen -
Vitaly Zaitsev -
Vít Ondruch