Bug 234446 - Rebuild failure due to missing dependencies.
Rebuild failure due to missing dependencies.
Status: CLOSED DUPLICATE of bug 235755
Product: Fedora
Classification: Fedora
Component: rpm (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Paul Nasrat
Depends On:
  Show dependency treegraph
Reported: 2007-03-29 07:34 EDT by David Woodhouse
Modified: 2013-01-09 23:14 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2007-07-18 15:03:44 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description David Woodhouse 2007-03-29 07:34:23 EDT
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 07:43:24 EDT
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 08:35:04 EDT
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-29 22:13:24 EDT
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 07:52:28 EDT
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 15:51:58 EDT
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 15:03:44 EDT

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