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_ architecture. 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.
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?
I'm looking at the latest rawhide tree right now: /mnt/redhat/nightly/rawhide-20070329/tree-ppc64/Fedora/kexec-tools-1.101-65.fc7.ppc64.rpm 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?
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...
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.
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, like 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. WONTFIX
*** This bug has been marked as a duplicate of 235755 ***