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/devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue