Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 234446 - Rebuild failure due to missing dependencies.
Summary: Rebuild failure due to missing dependencies.
Status: CLOSED DUPLICATE of bug 235755
Alias: None
Product: Fedora
Classification: Fedora
Component: rpm
Version: rawhide
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Paul Nasrat
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 2007-03-29 11:34 UTC by David Woodhouse
Modified: 2013-01-10 04:14 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2007-07-18 19:03:44 UTC

Attachments (Terms of Use)

Description David Woodhouse 2007-03-29 11:34:23 UTC
I tried building kexec-tools for ppc64, since it seems to be absent from
rawhide. It fails...

gcc -g -O2 -Wall -D_FILE_OFFSET_BITS=64 -DVERSION='"1.1.1"' -DRELEASE_DATE='"08
February 2007"' -D__powerpc__ -m64 x86.o x86_64.o ia64.o ppc64.o -o makedumpfile
makedumpfile.c -static -ldw -lelf -lz
/usr/bin/ld: skipping incompatible /usr/lib/libdw.a when searching for -ldw
/usr/bin/ld: cannot find -ldw
collect2: ld returned 1 exit status
make[1]: *** [makedumpfile] Error 1

The problem is that there is no dependency on the _correct_ version of
elfutils-devel-static. The current requirement for just 'elfutils-devel-static'
is satisfied by the existence of a 32-bit package with that name, which isn't
actually good enough. We should require elfutils-devel-static of the _same_

RPM currently doesn't let us just do 'Requires: elfutils-devel-static.%{arch}'.
It probably should. Alternatively, we could play tricks with file-based
requirements or add explicit 'Provides: %{name}.%{arch}' to everything we're
going to require that way.

Comment 1 David Woodhouse 2007-03-29 11:43:24 UTC
Reassigning to 'distribution' since this is a generic problem (although why
_isn't_ kexec-tools in rawhide?)

Is there a way that RPM can _infer_ the same-arch requirement without having to
make it explicit in the specfile?

One option might be for 'Requires: foo' to be satisfied by _either_ a 'noarch'
package of foo, _or_ a same-arch package of foo, but _not_ by an arch-specific
package of a different arch.

Sometimes the requirement _isn't_ for a package of the same arch though -- for
example if you only need to run a program, you could require /usr/bin/foo
instead of the 'foo' package. Or maybe we could allow 'Requires(anyarch): foo'
if file requirements aren't considered sufficient?

Comment 2 Neil Horman 2007-03-29 12:35:04 UTC
I'm looking at the latest rawhide tree right now:

So it would appear to me that kexec-tools is in fact in rawhide.  Where are you
looking to make you think that its not?

As for the rpm arch dependency issue, I agree that for the multilib space, it
would be good if rpm had sufficient granularity in its dependency specification
to allow arch specificity.  On the other hand, As I understand the environment,
when building in mock, the buildroot will get poulated with packages of the arch
being built for (i.e. in brew or other mock based systems, you're buildroot will
have all dependencies satisfied by packages of the same arch), so this problem
is limited to sandboxes on development systems.  Or am I missing something?

Comment 3 David Woodhouse 2007-03-30 02:13:24 UTC
On a similar note: 'yum --enablerepo=development update kernel' on FC6 removes
the FC6 'device-mapper' package and installs the rawhide 'device-mapper-libs'
package. The 64-bit version. Nash requires it by name, without being specific
enough about what it needs. I assume it uses dlopen()?

This system won't boot unless I go fix that by hand...

Comment 4 David Woodhouse 2007-03-30 11:52:28 UTC
Hm, kexec-tools seems to be in the ppc64 repo but _not_ the ppc repo. We should
have _both_ flavours of kexec-tools in the ppc repo.

Comment 5 Jeff Johnson 2007-03-30 19:51:58 UTC
Teaching one arch's distro about other arch's does not scale. Consider
aliasing: is the arch mentioned in the dependency x86_64? amd64? ia32e?

Choose an arch specific path (and add the path necessary) is one solution.

Another solution is to add an arch specific Provides: to each of the packages,
    Provides: foo.%{_target_cpu}
with teh obvious Requires: added as well.

The mechanism to solver your problem already exists within rpm and requires
no additional implementation.


Comment 6 Panu Matilainen 2007-07-18 19:03:44 UTC

*** This bug has been marked as a duplicate of 235755 ***

Note You need to log in before you can comment on or make changes to this bug.