yum-builddep pulling in i386 packages for x86_64 -devel dependencies

[Panu Matilainen]

On Sun, 8 Mar 2009, James Antill wrote:

> On Fri, 2009-03-06 at 20:38 -0500, Steve Grubb wrote:
>> On Friday 06 March 2009 04:44:00 am Bill Crawford wrote:
>>> I just noticed an interesting thing with yum-builddep. There's a dependency
>>> somewhere on audit-libs-devel, and it's trying to pull in audit-libs.i386
>>> instead of .x64_64 ... this then leads to it wanting to download over a
>>> dozen other i386 packages. Any way to get around this? Did I do something
>>> wrong?
>>
>> This sounds like something is wrong in the build system. Where a package is
>> built on a multi-lib platform, isn't there an explicit "--target x86_64" ? If
>> so, rpm has the hint needed to resolve this all successfully. If rpm simply
>> chose only packages from the arch that is being built, there wouldn't be a
>> problem. Its that simple.
>
> It's yum, not rpm, and yes ... it contains code so that it often picks
> the "right" package when the Requires information just says "I want XYZ"
> and we have XYZ.i386 and XYZ.x86_64 but the package will only work with
> one of them.
> Saying that if it picks badly then 99% of the time the best fix is
> going to be to change the requires so it says "I want XYZ%{_isa}".
> If you think it's easier to make the yum depsolver more magic, than add
> 7 characters to your specfile, patches are accepted.

If I understood this correctly, in this case there is sufficient 
information to pull in the correct package already. Looking at 
http://koji.fedoraproject.org/koji/rpminfo?rpmID=1075605 pointed to 
earlier in the thread:

Requires:
    audit-libs = 1.7.12-2.fc11
    libaudit.so.0()(64bit)
    libauparse.so.0()(64bit)

The soname dependencies point to the correct version of audit-libs 
already, just the manual dep on audit-libs (to force exact version 
match) is satisfied with any arch.

It'd be possible to weigh the dependencies, preferring automatic 
dependencies over manual ones and if manual dependencies are still 
unresolved after resolving automatic ones, only then try to look for them. 
Except the full dependency flags aren't stored in repodata, only GE/LE/EQ
etc so this wont work.

What should work for this case is resolving the dependencies with only one 
provider first and if after that there are still unresolved deps, try to 
resolve them. "Only one provider" here assumes only looking at newest 
packages (which I think yum already does).

 	- Panu -