Name for commandline software management tool - DNF or DNF5?

[j-mracek]

There is on going discussion (Fedora-devel-Fedora 39 proposal) about naming of the next generation of software management tool. The new package will provide dnf, yum, dnf5, and microdnf and symlink or binary to ensure compatibility, upgrade path, install path (dnf install dnf|microdnf|yum|dnf5 => install the new tool) and improve adoption speed.

There are several questions which I would like to ask community (Fedora, RHEL, upstream developers)

• What name (**dnf**, yum, **dnf5**, or microdnf ) should we use for a package providing binary (currently DNF5)?
• What binary name or symlink should we use in man pages (currently DNF5) for examples?
• What binary name or symlink should we use in Fedora guidelines?
• What binary name or symlink should we use in RHEL guidelines?
• How should we name packages containing plugins (additional command)?

Additional information

The new tool is accompanied with library that provide bindings (Python, ...). The new library cannot be named libdnf therefore we named it as libdnf5. Package providing the new Python bindings cannot be named pythonX-libdnf, or pythonX-dnf, therefore we named it pythonX-libdnf5. The new bindings will be imported in Python as libdnf5. If we use the same names as DNF used, we will break a lot of thing on during runtime, because package requirements will not help us (Requires dnf > 4.0.0 can be satisfied by both library).

In Fedora 38 the new package (dnf5) is deployed to replace microdnf, and cannot be named as dnf there because we cannot replace DNF in Fedora 38.

I would like to describe 3 basic scenario how we can deploy the new tool in Fedora 39. Please consider that scenarios do not contain all details.

1. Proposed deployment as DNF5

Pros

• clearly highlighted that user is using a different tool with compatibility layer to previous tool with a different set of plugins
• clear difference whether documentation refers to dnf or dnf5

Neg

• documentation will suppose to modify to use DNF5

New command-line tool will be shipped in dnf5 package that will provide dnf, microdnf, yum, dnf5, /usr/bin/yum, /usr/bin/dnf, /usr/bin/dnf5, /usr/bin/microdnf, Obsoleting dnf, microdnf, yum, Conflicting with dnf.

man dnf, man dnf5, man microdnf, and man yum will open dnf5 man pages. Man pages will use examples with dnf5 command, but man pages will state that dnf5 provide dnf and other aliases.

Plugins for dnf5 (commands, modifier of output) will be packages as dnf5-plugins

2. Alternative deployment as DNF

Pros

• documentation will only require modify the examples that differences in the new tool.

Neg

• not clear difference whether documentation refers to dnf or dnf5
• not clear message that the tool was exchanged - missing features, syntax change could more negatively surprise users
• plugin change will be not transparent - Fedora 39 will ship dnf plugins with same name pattern for the new dnf and the old dnf.

New command-line tool will be shipped in dnf package (dnf5 package from Fedora 38 will be renamed to dnf) that will provide dnf, microdnf, yum, dnf5, /usr/bin/yum, /usr/bin/dnf, /usr/bin/dnf5, /usr/bin/microdnf, Obsoleting microdnf, yum, dnf5, Conflicting with dnf-deprecated.

man dnf, man dnf5, man microdnf, and man yum will open dnf5 man pages. Man pages will use examples with dnf5 command, but man pages will state that dnf5 provide dnf and other aliases.

Plugins for the new dnf (commands, modifier of output) will be packages as dnf-plugins. Here I see a confusion because the old dnf also ship its own plugins as dnf-plugins. Good new is that plugins for dnf4 require python3-dnf.

Additional it will ship old dnf as dnf-deprecated, but it will be not installed after system-upgrade. If any tool wants to use old DNF they need to start require dnf-deprecated.

3. Alternative deployment as DNF5 package but using DNF as primary command

Pros

• clearly highlighted that user is using a different tool with compatibility layer to previous tool with a different set of plugins, features, ...
• documentation will only require modify the examples that differences in the new tool.

Neg

• not clear difference whether documentation refers to dnf or dnf5

New command-line tool will be shipped in dnf5 package that will provide dnf, microdnf, yum, dnf5, /usr/bin/yum, /usr/bin/dnf, /usr/bin/dnf5, /usr/bin/microdnf, Obsoleting dnf, microdnf, yum, Conflicting with dnf.

man dnf, man dnf5, man microdnf, and man yum will open dnf5 man pages. Man pages will use examples with dnf command, but man pages will state that it provides other aliases.

Plugins for dnf5 (commands, modifier of output) will be packages as dnf5-plugins.

[j-mracek]

Somehow I have a feeling that the last option (Alternative deployment as DNF5 package but using DNF as primary command) can provide the most of benefits.

[timlau]

As i see it, DNF5 is a new application, not just a new mayor version, so it should be packaged as dnf5, but should use dnf as binary

the python binding should properly be named python3-dnf5, then lib naming is not used very often in python

[mcurlej]

As we already named the package in the previous version of Fedora to accommodate the new software (DNF5) i would not change it. DNF5 represents a new application so it should have its own package name.

With regards to backwards compatibility it should have symlinks to cover most usage by the users (dnf5, dnf, yum etc.)

So from my point of view the 3rd option makes the most sense.

With regards to the documentation, if my system has installed DNF5 by default and i write man dnf i want the documentation to my default tool i am using. I know there can be special cases, but special cases are not default. So this will be not an widespread issue...

[dmnks]

We may want to get some inspiration from how the introduction of Python3 was handled in Fedora, which seems to resemble the DNF5 situation quite a bit. Currently, it's shipped as the python3 package containing the /usr/bin/python3 binary. There's also the python-unversioned-command package which ships the /usr/bin/python -> /usr/bin/python3 symlink.

It can be argued the Python3 transition has set a precedent for how these major upgrades should (can) be handled (in Fedora), so we might as well follow the lead?

[voxik]

I thought I won't participate, but honestly, the results of Python 3 migration is the worst example. I can't believe that we have "python-" SRPM packages while they produce "python3-" RPMs.

[dmnks]

What would have been the better solution then?

[dcantrell]

I am coming in to this discussion late, but I have some comments. Generally speaking I think it's bad form to incorporate the software major version as part of the name. There are well known examples where this has become established and accepted, but it does lead to changes or conflicts down the road. The one I am thinking about is Perl where the world just ran with "perl5" because perl4 was already out in the wild and perl5 was significantly different and also early on was installed alongside perl4 (which was already called "perl"). Skip to now and they tried to continue with perl6, but eventually ended up renaming that effort to raku and just let Perl continue as "perl5".

Personally, I wish the yum to dnf name change never happened, but here we are. "dnf" is established as a command name now and that's fine. It's worth considering how versioning of dnf will work going forward. Will there be a dnf major version 6? 7?

I understand the dnf5 transition is quite significant. And it needs to coexist with the existing dnf for at least some time. I think the command names going forward should push for "dnf" as the preferred name even if "dnf5" comaptibility symlinks are provided. As for naming the software, I think a name like dnfutils or dnftools is more appropriate than "dnf5". The name would avoid stomping on the existing "dnf" package name, but it would remove the major version from the software package names, which I think is something worth avoiding.

[ppisar]

I like the third option most. Since the desired state is replace DNF4 with DNF5, when that happens, I would rename as much of the tools, manual pages, examples, packages back to dnf without a version. If there is a technical requirement to keep a distinct name (e.g. a completely different API of the Python library), then keep it with the number. However, things which aspire to resemble DNF4 (e.g. dnf command) should be unversioned.

[jan-kolarik]

I think that everything has been already said there 🙂 I also agree with the 3rd option. Binary is different now, therefore we're gonna have a dnf5 package. But for the command-line users we want to preserve the (almost) same user experience as with the dnf command, so keeping the same name there fits me better.

[Conan-Kudo]

I would generally prefer unversioned names for everything.

[major]

Option 3 sounds optimal because:

1. Developers (or people who are interested in dnf development) can see the difference
2. End users run dnf like they always did and they're happy

[keszybz]

Option 3 for me too.

The plan is to make dnf-3 and dnf5 co-installable for some time. That would be significantly harder with option 2, and is much easier with option 3. The only thing that needs to change when the default is flipped is who provides the symlink. This is much easier than changing the package name.