how to have yum prefer one dependency over others

Panu Matilainen pmatilai at
Sat Sep 17 14:23:06 UTC 2011

On 09/16/2011 11:53 PM, Michael Schwendt wrote:
> On Fri, 16 Sep 2011 13:49:36 -0400, SV (seth) wrote:
>> There are still a largish number of packages out there that have things
>> like:
>> Requires: foo
>> where they really want:
>> Requires: foo(64bit)
> Fixing this in some packages is not entirely easy.
> Why? Because whereas the %{name}%{?_isa} Provides are automatic,
>    $ rpm -q --provides glib2|grep ' = '
>    glib2 = 2.29.90-1.fc16
>    glib2(x86-64) = 2.29.90-1.fc16
> some packages depend on virtual capabilities in order to make external
> dependencies much more strict. E.g.
>    Provides: foo(abi) = 5
> These are not arch-specific. How to convert from what we have so far to
> the new era of adding an explicit %{?_isa} everywhere? Where we have a
>    Requires: foo(abi) = 5
> we cannot simply add an explicit arch-specific dep on the package name,
>    Requires: foo(abi) = 5
>    Requires: foopkg%{?_isa}
> can we?
> What happens if foopkg is upgraded to foo(abi) = 6? Yum will still run a
> cross-arch search for a foo(abi) provider and on x86_64 may find it in an
> older i686 package that's still in the repo, too.
> It seems we need to make the full show arch-specific:
>    Provides: foo(abi)%{?_isa} = 5
> and
>    Requires: foo(abi)%{?_isa} = 5
> For released dists that will break dependencies and require rebuilds.

For manually added provides such a thing can be easily done gradually 
without flag-days: add an isa-specific provides along the non-isa 
version, adjust requiring packages when suitable and then finally remove 
the non-isa provides when nothing needs them anymore.

Of course its not always that simple: There are various cases where the 
arch/isa simply isn't known, for example pkg-config requires generation 
has no way of knowing whether a particular dependency is arch-dependent 
or not. Python with its ambiguous use of /usr/lib is another pile of 
fun, etc.

%{_isa} is as klunky as it is because it's just a stupid build-time 
macro which allows *somehow* expressing the arch-dependency without 
changes to the entire repository + packaging toolchain, including 
buildsys builders which are pretty much by definition always running 
much older versions of rpm & yum (yes they had a custom-built newer rpm 
for a period of time when the builders were RHEL 5, but I doubt anybody 
would be too happy to repeat that experience).

Rpm could certainly be taught nicer mechanisms to permit packages to 
specify whether their dependency can be satisfied by a package of 
different arch/isa-style thingie (and various other tricks), but with 
everybody doing their own depsolving without ever really asking from rpm 
(heck, one of the points behind the repodata was to get rpm OUT of the 
depsolving loop), anything like this requires changing not just the 
rather frozen-format repodata but teaching the same things over and over 
againt o different tools. And because its so bloody painful nobody 
really bothers.

The near-flamefest on this thread over whose depsolver is the best is 
largely besides the point: in a perfect world there would be just one 
Grand Unified Depsolver (library) that everything including rpm itself 
would use. And in order for rpm to be able to use it, it'd have to be 
implemented in C. Whether its *in* rpm or something external (such as 
libsatsolver) is a different question entirely.

Now there's a nice little pet-project for somebody ;)

	- Panu -

More information about the devel mailing list