On Fri, Feb 11, 2022 at 7:42 PM Miro Hrončok <mhroncok@xxxxxxxxxx> 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@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 on the list, report it: https://pagure.io/fedora-infrastructure
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 on the list, report it: https://pagure.io/fedora-infrastructure
