F39 proposal: Replace DNF with DNF5 (System-Wide Change proposal)

[Ben Cotton]

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(a)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/[e-mail].o...
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 ==



-- 
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis

[Vitaly Zaitsev]

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?

-- 
Sincerely,
   Vitaly Zaitsev (vitaly(a)easycoding.org)

[Jaroslav Mracek]

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.

[Milan Crha]

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

[Nico Kadel-Garcia]

On Thu, Sep 8, 2022 at 8:27 AM Milan Crha <mcrha(a)redhat.com&gt; 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.

[Milan Crha]

On Thu, 2022-09-08 at 08:39 -0400, Nico Kadel-Garcia wrote:
>  installing parallel versions of the same development tools 
	Hi,
Jaroslav said they are not the same, hence I asked.
	Bye,
	Milan

[Jaroslav Mracek]

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.

[Adam Williamson]

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.
-- 
Adam Williamson
Fedora QA
IRC: adamw | Twitter: adamw_ha
https://www.happyassassin.net

[Jaroslav Mracek]

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.

[Maxwell G]

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?

-- 
Maxwell G (@gotmax23)
Pronouns: He/Him/His

[Maxwell G]

Sep 8, 2022 8:45:19 AM Maxwell G via devel 
<devel(a)lists.fedoraproject.org&gt;:

>  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

[Richard W.M. Jones]

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.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
Fedora Windows cross-compiler. Compile Windows programs, test, and
build Windows installers. Over 100 libraries supported.
http://fedoraproject.org/wiki/MinGW

[Jaroslav Mracek]

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

[Josh Boyer]

On Tue, Sep 6, 2022 at 2:29 PM Ben Cotton <bcotton(a)redhat.com&gt; 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(a)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/[e-mail].o...
>  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(a)lists.fedoraproject.org
> To unsubscribe send an email to devel-leave(a)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/[e-mail]
> Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue

[Neal Gompa]

On Wed, Sep 7, 2022 at 3:17 PM Josh Boyer <jwboyer(a)fedoraproject.org&gt; wrote:
>  On Tue, Sep 6, 2022 at 2:29 PM Ben Cotton <bcotton(a)redhat.com&gt; 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(a)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/[e-mail].o...
>  > 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!

[Jaroslav Mracek]

>  On Wed, Sep 7, 2022 at 3:17 PM Josh Boyer
> <jwboyer(a)fedoraproject.org&gt; 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!

[Jaroslav Mracek]

>  On Tue, Sep 6, 2022 at 2:29 PM Ben Cotton
> <bcotton(a)redhat.com&gt; 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
>

[Marius Schwarz]

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

[Fabio Alessandro Locati]

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
-- 
Fabio Alessandro "Fale" Locati
fale.io

[Jaroslav Mracek]

Correct, DNF5 will provide a library - LIBDNF5 that will provide C++ API plus bindings to
various languages including Python.

Jaroslav

[Tommy Nguyen]

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.

[Jaroslav Mracek]

Happy to hear that.

Jaroslav

[Jaroslav Mracek]

>  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

[Otto Liljalaakso]

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?

[Jaroslav Mracek]

>  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

[Tommy Nguyen]

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.

[Kevin Kofler]

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

[Tommy Nguyen]

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.

[Sandro]

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

[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.

[Marius Schwarz]

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

DNF5 wants to replace regular rpms with modules

[Otto Liljalaakso]

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.

DNF5 wants to replace regular rpms with modules

[Petr Pisar]

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(a)iki.fi&gt; 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(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)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/[e-mail]
>  Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue

DNF5 wants to replace regular rpms with modules

[Jaroslav Mracek]

Correct, the modular filtering is not yet implemented and this is the last blocker for
rawhide release.

Jaroslav Mracek

DNF5 wants to replace regular rpms with modules

[Rahul Sundaram]

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

[Maxwell G]

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

[Maxwell G]

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

[Brian C. Lane]

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

-- 
Brian C. Lane (PST8PDT) - weldr.io - lorax - parted - pykickstart

[Jaroslav Mracek]

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.

[Kevin Fenzi]

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

[Jaroslav Mracek]

>  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

[Vít Ondruch]

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(a)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/[e-mail].o...
>  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 ==
>
>
>
>

[Miroslav Suchý]

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

[Stephen Smoogen]

On Wed, 12 Oct 2022 at 09:49, Miroslav Suchý <msuchy(a)redhat.com&gt; 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(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)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/[e-mail]
>  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

[Kevin P. Fleming]

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 :-)

-- 
Kevin P. Fleming
He/Him/His
Principal Program Manager, RHEL
Red Hat US/Eastern Time Zone

[Stephen Smoogen]

On Wed, 12 Oct 2022 at 10:32, Kevin P. Fleming <kpfleming(a)redhat.com&gt; 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(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)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/[e-mail]
>  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

[Alexander Sosedkin]

On Wed, Oct 12, 2022 at 4:47 PM Stephen Smoogen <ssmoogen(a)redhat.com&gt; wrote:
>  On Wed, 12 Oct 2022 at 10:32, Kevin P. Fleming
> <kpfleming(a)redhat.com&gt; 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. =)

[Neal Gompa]

On Wed, Oct 12, 2022 at 11:15 AM Alexander Sosedkin
<asosedkin(a)redhat.com&gt; wrote:
>  On Wed, Oct 12, 2022 at 4:47 PM Stephen Smoogen <ssmoogen(a)redhat.com&gt; wrote:
>  > On Wed, 12 Oct 2022 at 10:32, Kevin P. Fleming <kpfleming(a)redhat.com&gt; 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



-- 
真実はいつも一つ！/ Always, there's only one truth!

[Sandro]

On 12-10-2022 17:19, Neal Gompa wrote:
>  On Wed, Oct 12, 2022 at 11:15 AM Alexander Sosedkin 
>  <asosedkin(a)redhat.com&gt; wrote:
> > 
> > On Wed, Oct 12, 2022 at 4:47 PM Stephen Smoogen
> > <ssmoogen(a)redhat.com&gt; wrote:
> >> On Wed, 12 Oct 2022 at 10:32, Kevin P. Fleming
> >> <kpfleming(a)redhat.com&gt; 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

[Jonathan Wright]

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(a)redhat.com&gt;
wrote:

>  On Wed, Oct 12, 2022 at 4:47 PM Stephen Smoogen
> <ssmoogen(a)redhat.com&gt;
>  wrote:
>  > On Wed, 12 Oct 2022 at 10:32, Kevin P. Fleming <kpfleming(a)redhat.com&gt;
>  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(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)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/[e-mail]
>  Do not reply to spam, report it:
>  https://pagure.io/fedora-infrastructure/new_issue
>  

-- 
Jonathan Wright
AlmaLinux Foundation
Mattermost: chat <https://chat.almalinux.org/almalinux/messages/@jonathan>

[Chuck Anderson]

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(a)redhat.com&gt; 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...

[Panu Matilainen]

On 10/12/22 17:47, Stephen Smoogen wrote:
>  
>  
>  On Wed, 12 Oct 2022 at 10:32, Kevin P. Fleming <kpfleming(a)redhat.com 
>  <mailto:[e-mail]>> 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 -

[Pierre-Yves Chibon]

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(a)redhat.com
>  > <mailto:[e-mail]>> 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

[Neal Gompa]

On Wed, Oct 12, 2022 at 10:31 AM Kevin P. Fleming <kpfleming(a)redhat.com&gt; 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. :)


-- 
真実はいつも一つ！/ Always, there's only one truth!

[Vít Ondruch]

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(a)redhat.com&gt; 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(a)lists.fedoraproject.org
>      To unsubscribe send an email to devel-leave(a)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/[e-mail]
>      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(a)lists.fedoraproject.org
>  To unsubscribe send an email todevel-leave(a)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/[e-mail]...
>  Do not reply to spam, report it:https://pagure.io/fedora-infrastructure/new_issue
>

[Jaroslav Mracek]

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

[Vít Ondruch]

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

[Mattia Verga]

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

[Miroslav Suchý]

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

[Jaroslav Mracek]

>  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

[Jaroslav Mracek]

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

[Vít Ondruch]

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(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)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/[e-mail]
>  Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
>

[Jaroslav Mracek]

>  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

[Rahul Sundaram]

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

[Jaroslav Mracek]

>  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

[Sandro]

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. :)

[José Abílio Matos]

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,
-- 
José Abílio Matos

[Mattia Verga]

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

[Jaroslav Mracek]

>  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

[Jaroslav Mracek]

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_relate...

Jaroslav

[Vít Ondruch]

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.
>
>

[Jaroslav Mracek]

>  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

[Vít Ondruch]

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(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)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/[e-mail]
>  Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
>

[Jaroslav Mracek]

>  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

[Dominik 'Rathann' Mierzejewski]

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
-- 
Fedora   https://getfedora.org  |  RPM Fusion  http://rpmfusion.org
There should be a science of discontent. People need hard times and
oppression to develop psychic muscles.
        -- from "Collected Sayings of Muad'Dib" by the Princess Irulan

[Jaroslav Mracek]

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.

[Vít Ondruch]

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(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)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/[e-mail]
>  Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
>

[Vít Ondruch]

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(a)lists.fedoraproject.org
> > To unsubscribe send an email to devel-leave(a)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/[e-mail]
> > Do not reply to spam, report it: 
> > https://pagure.io/fedora-infrastructure/new_issue
>

[Jaroslav Mracek]

>  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

[Vít Ondruch]

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

[Kalev Lember]

On Tue, Dec 20, 2022 at 2:16 PM Vít Ondruch <vondruch(a)redhat.com&gt; 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.

-- 
Kalev

[Jaroslav Mracek]

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

[Vít Ondruch]

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(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)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/[e-mail]
>  Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
>

[Dominik 'Rathann' Mierzejewski]

On Wednesday, 21 December 2022 at 12:31, Vít Ondruch wrote:
[...]
>  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. 
This is a very good summary of my opinion as well. Thanks, Vit!

Best regards,
Dominik
-- 
Fedora   https://getfedora.org  |  RPM Fusion  http://rpmfusion.org
There should be a science of discontent. People need hard times and
oppression to develop psychic muscles.
        -- from "Collected Sayings of Muad'Dib" by the Princess Irulan

[Chuck Anderson]

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:
>  > 
>  > 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.
>  
>  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.

[Vít Ondruch]

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:
> >>
> >> 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.
> > 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(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)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/[e-mail]
>  Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
>

[Jaroslav Mracek]

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

[Barry Scott]

>  On 19 Dec 2022, at 16:50, Jaroslav Mracek <jmracek(a)redhat.com&gt;
> 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

[Jaroslav Mracek]

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