On 02/20/2014 03:44 PM, Colin Walters wrote: > On Thu, Feb 20, 2014 at 7:27 AM, Florian Festi <ffesti@xxxxxxxxxx> wrote: >> We are currently working on adding weak and rich dependencies to >> upstream RPM. There are basically two parts: > > Is someone signed up to do the necessary frontend work for this on the > dnf/yum side? If we're allowing choice of "A | B" like this, there > needs to be a frontend that actually allows choosing, like aptitude. Yes and no. Right now there is no plan to allow the user to do the choosing. This ambiguity already exists in the current relations and we will continue to handle it automatically. > I guess one could go with the "shortest package name wins" approach or > whatever the current heuristic is for now... The heuristics will improved though. Libsolv already uses weak dependencies to choose the "more desired" package. I hope we can add support for preferring the more left packages over later packages in such or-clauses. That way Requires: sendmail or postfix would prefer sendmail while Requires: MTA chooses one of them the by some unrelated criteria. > This is also relevant with things like kickstart files, where there is > no interactivity allowed. > > (For what it's worth I think making packaging even more complex and less > predictable in order to increase flexibility is precisely the opposite > direction of what we should be doing...but that's OK because I am coming > at this from the other direction. We'll meet in the middle somehow ;) ) Actually I am on your side of the argument. This effort is supposed to give better control over how packages behave and relate to each other *to the packager*. While "A or B" is an often demanded feature the main reason for this are relations that span a longer distance. E.g. Foo-langpack-es could Supplement: Foo and langsupport-es Or to implement the same behaviour with a forward dependency package Foo could Requires: Foo-langpack-es if langsupport-es Both variants pull in a intermediate package (Foo-langpack-es) if two packages are present (Foo and langsupport-es). Florian PS: I actually do think that we need to give the user more control over the packages, too. The current tools are completely inadequate to manage the number of packages we have in the distribution or even just on a system. But this is a story for another time. -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
