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

[Florian Festi]

On 02/20/2014 11:50 PM, Adam Williamson wrote:
> On Thu, 2014-02-20 at 14:44 +0000, 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.
> 
> Fedora isn't signed up to *use* it yet. We can still make the choice
> whether we want to or not, I believe.

Yup. And more important how to use them. While the two levels of
weakness is the most obvious feature it is IMHO not the most important
one. We are basically introducing the weaker level only for two reasons:
That's what all other implementations do and it matches the structure of
comps and thus may allow doing something group like in native rpm terms
in the future.

I have not yet seen an convincing use of those levels of weakness. If
Fedora is willing to put some serious effort into this it might being
used to have different package sets for the different Fedora.next
products by setting different defaults. But whether that's feasible is
still an open question IMHO.

The more interesting features are:

No longer rely on other packages. With "foo or bar" you can choose
between packages that do not have a common provide. With the reverse
relations you can attach your package to another one without changing
it. Being able to create 3rd party packages was one of the design goals
of RPM and not being able to do such things from your own package breaks
that. While this is not that important for the closed world view of a
distribution it will become more important with COPR.

Another important thing is being able to deal with more complicated
situations. One kind are multilib problems like #442047 and #663269. I
am pretty sure there are others, too.

More interesting from a user perspective are bridging packages like
language packs (see my previous mail) or optional plugins. Right now we
need hand coded solutions like yum-langpack for something that should
just be done by the packaging system.

Florian