Re: F39 proposal: Replace DNF with DNF5 (System-Wide Change proposal)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



> Dne 17. 10. 22 v 9:28 Jaroslav Mracek napsal(a):
> 
> 
> So why there is proposed the `/usr/bin/dnf` symlink? To create the 
> confusion again?

For Fedora 38 we cannot ship DNF binary. We also cannot provide dnf, hawkey or libdnf in Python bindings, because the those name spaces are already taken by DNF, LIBDNF and there is a requirement to keep python3-dnf around (Fedora 39). Then we want to unify brand - therefore we do not want to ship product with one name, providing different name for bindings and so on. 

 
 
> 
> This ^^ is self-imposed restriction. From practical POV, if DNF5 works 
> and provides all required functionality, there is no need for parallel 
> installability.
> 

Porting to DNF5 API will require some transition period even when all required functionality will be in place.

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

DNF team has experience with replacing of YUM in Fedora and RHEL. It give us an advantage to not repeat the same mistakes. We already know that shipping DNF as YUM was not a good idea. There was a lot of confusions therefore in RHEL9 we ship DNF as DNF and not YUM. DNF provides great compatibility with YUM but anyway it was not the best move that we did. The naming is really tricky and we cannot satisfy everyone.

Jaroslav

> 
> 
> Vít
_______________________________________________
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




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux