Fwd: [Rpm-maint] Heads up: Weak and rich dependencies in RPM

[Florian Festi]

On 02/20/2014 03:44 PM, Colin Walters wrote:
> On Thu, Feb 20, 2014 at 7:27 AM, Florian Festi <ffesti at redhat.com> 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.