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 -
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
