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@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx 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@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Attachment:
OpenPGP_signature
Description: OpenPGP digital signature
_______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx 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@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
