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