Bug 234446
Summary: | Rebuild failure due to missing dependencies. | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | David Woodhouse <dwmw2> |
Component: | rpm | Assignee: | Paul Nasrat <nobody+pnasrat> |
Status: | CLOSED DUPLICATE | QA Contact: | |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | rawhide | CC: | dcantrell |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2007-07-18 19:03:44 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
David Woodhouse
2007-03-29 11:34:23 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? 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 |