On Fri, Feb 11, 2022 at 7:42 PM Miro Hrončok <mhron...@redhat.com> wrote:
> On 11. 02. 22 13:50, Jaroslav Mracek wrote: > > > No we didn't and it will make the feature less usable - see > reported issues > > > during testing in original request ( > > > https://bugzilla.redhat.com/show_bug.cgi?id=1699672#c74 > > <https://bugzilla.redhat.com/show_bug.cgi?id=1699672#c74>). > > > > Miro's reply was: "That was expected and we can make sure our > > packaging guidelines discourage Recommedns with full [NEVR]". Then > there was > > follow-up discussion with general agreement that the example from > #c74 was in > > fact a packaging mistake. In fact there was some discussion of > amending the > > guidelines. > > > > > > DNF is not a component only in Fedora and we have to support the LEGACY > point > > of view. Changing guidelines is not an option because they are not > mandatory > > but something as a recommendation. People will anyway ship packages with > > versioning of relation dependencies because they want, they can and they > need > > them. Creating such a rule will only make things worse. > > Let's take a step back, since I feel we've derailed. We appear to be > discussing > two related but different things: > > - behavior of a new dnf option > - whether or not the new option should be turned on by default in Fedora > > If dnf needs to support use cases of another distro (say legacy RHEL), > that can > easily happen by not changing the default there. Maybe I just don't see > the > whole picture? > The feature was requested by Fedora and RHEL community to resolve multiple use cases. It means it was requested to provide the feature by default enabled on both systems (Fedora 36, RHEL9). Personally I am really scared to ship something to RHEL but not into Fedora. > What I'd like to understand better is how option 3 (which seems to be > preferred > by you, if I am not mistaken) makes this situation any different. Why do > you > assume the impact on legacy systems will be smaller if we go with option 3? > With LEGACY user cases I was directly reacting to the option to change packaging guigelins. DNF in fedora 36 must handle correctly packages builded for even older Fedoras. The same for the RHEL. Anyway the version problem is not a problem anymore. We have autodetection of unmet weak dependencies that works correctly with one exception - situations when rich dependencies are used. Therefore modifying only this part will have the best effect on the feature. I do not say that it is perfect and there will be no pain, but we can improve it. Postponing it will only move discovering problems to the future. The autodetection can work nearly perfectly for Recommends but even there it will not resolve every situation perfectly, because two people with the same operation can have completely different expectations. Therefore we have to optimize it so that the majority of users will be happy. The other situation is with Supplements - we do not have all information like for Recommends because they are stored in available metadata (repositories) that are gone after metadata refresh. It means we have to make an assumption for autodetection. According to reports the default assumption was wrong for Supplements with rich deps. What I do here is to modify the algorithm for autodetection and see whether it will satisfy more user cases that present implementation. The algorithm cannot be perfect because it is based on the assumption of what users want. As I said several times, it is very complicated but I believe it will be beneficial to users and postponing it will not help in any way. > Changing guidelines might as well work in Fedora, as Zbyszek said. We can > fix > the packages easily. I can even offer my help to do it and even attempt to > do > it in c9s. > > I understand that packagers will always break the rules. That is not a > phenomenon specific to weak dependencies. When they do, we can fix it. And > when > we don't fix it, the worst case is they get the behavior that was the > default > until now. That doesn't sound that bad to me: Packagers who follow the > rules > will get nice things, packagers that don't will get things that ain't that > nice > but still work. > Changing packaging guidelines is not an option for 99.9% of the community. Miro I know you can but not others, therefore I develop a solution that resolves the issue with versions without changing packing guidelines. And it works, therefore we do not need to change them. > Another thing I'd like to understand from your POV is why would packagers > actually *need* exactly-versioned Recommends. Could you please give me an > example use case? I understand why they might *assume they need* it, > because > packaging is complex and this might seem like a reasonable thing to do for > somebody who's not been following this discussion. The new guideline would > help > explain that, making the things better, not worse. > Don't ask me, people use it therefore there are usecasses. I suggest that it nicely modifies solver behaviour to trigger upgrade of recommended packages on upgrade but I am not sure. -- > Miro Hrončok > -- > Phone: +420777974800 > IRC: mhroncok > _______________________________________________ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@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 on the list, report it: > https://pagure.io/fedora-infrastructure Jaroslav
_______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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 on the list, report it: https://pagure.io/fedora-infrastructure
