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