PLD Linux and Obsoletes

[Gustavo Niemeyer]

Hy Patryk!

It's great to see you here.


> In PLD Linux we provide some mutually exclusive packages. Like LPRng
> versus cups.
> 
> They are marked by all providing and obsoleting some virtual name:
> 
> Name: foo
> Provides: baz
> Obsoletes: baz
> 
> Name: bar
> Provides: baz
> Obsoletes: baz

As far as my understanding of rpm packaging goes, this looks a bit
confusing.  Mutually exclusive packages should be marked with Conflicts
clauses rather than Obsoletes, so that you don't get the implicit
"foo is obsolete and should be upgraded by bar" behavior.  Not even
considering packaging relations, how can two entities obsolete each
other mutually?


> Smart treats all Obsoletes as final and in the above situation results
> in cycling between foo and bar with each upgrade attempt. This is
> certainly not the desired situation so I thought I'd ask here if there
> were any plans to handle such situations (not very common in most
> distros as they provide "the one and only app" for each task) by
> ignoring Obsoletes that are matched by a virtual Provide (not matched
> by a NameProvide).

You really seem to be looking for a Conflicts relation here.  We can
try to transform one relation into the other dynamically when such cases
are found, if you can't handle the relation switching.


> First I thought I might be able to patch this myself but the code is
> not very straightforward for a newcommer (not sure where to start).

I can try to fix the issue myself, but it'd be good for us to talk
about it anyway.  I'm "niemeyer" on FreeNode.


> Another issue I'm experiencing at the moment is that smart does not
> handle "Requires: uname(release) >= 2.6.20" kind of system
> dependencies introduced in recent releases of rpm. We also use those
> and currently it's impossible to install such packages using smart.

Jeff will beat me in the head about that. :-)  I'll make sure it's fixed
for the next release.

-- 
Gustavo Niemeyer
http://niemeyer.net