PLD Linux and Obsoletes

[Jeff Johnson]

On Aug 1, 2007, at 9:38 AM, Patryk Zawadzki wrote:

> Hi,
>
> My first post here so forgive me if that was already discussed.
>
> 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
>
> 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).
>

There's no simple solution within packaging for many reasons,
not the least of which is whether Obsoletes: should be by RPMTAG_NAME
or by RPMTAG_PROVIDENAME, and whether Obsoletes: should be
persistent. Without clear answers to those questions, its impossible
to design a packaging or depsolver solution.

Meanwhile, the KISS principle says pin one of the two alternatives.
smart almost certainly has that apt-like functionality.

> 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).
>
> 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.
>

Doing
     echo "uname(release) = 2.6.20" > /etc/rpm/sysinfo/Providename
is one way to satisfy the dependency. Dunno what rpm is being used ...

Upgrading rpm, or preparing packages that can be installed with
functionality that is actually available on the client, is the better  
fix however.

hth

73 de Jeff