Bug 212523
Summary: | rpmbuild lets x86_64 packages satisfy BR's when building for i386 | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Hans de Goede <hdegoede> |
Component: | rpm | Assignee: | Paul Nasrat <nobody+pnasrat> |
Status: | CLOSED DUPLICATE | QA Contact: | |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | rawhide | ||
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:04:13 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
Hans de Goede
2006-10-27 08:23:46 UTC
There's nothing stopping you from adding arch-specific dependencies to existing dependencies. Adding Provides: %{name}.%{_arch} by overloading the %description section separator to add to every package just like -debuginfo does. The narrow case you mention -- of having -devel depend on the base.arch package -- might also be automated, but would be trickier. And arch-colored dependencies aren't going to succeed any better than %{dist} in Release: "works" because arch is the wrong attribute to add to dependencies. All of your suggestion was considered (and discussed with others) before I chose to implement multilib dependencies based on elf32 and elf64. "... things aren't that easy ..." Sorry, I left out " ... -- Requires: %{name}.%{_arch} might also be automated transparently in spec files ..." in the sentence above. Hmm, So you're suggesting that to fix this at the packaging level, I add to foo-devel: Provides: foo-devel.%{_arch} = %{version}-%{release} And then to bar: BuildRequires: foo-devel.%{_arch} or: BuildRequires: foo-devel.%{_arch} > 1.0 Thinking about this somemore would it be possible for rpmbuild to check all the BR's + dependencies to see if they provide any .so 's and then check that they provide the correct (elf64 vs elf32) so's for the arch which is currently being build? Basically yes. If you're really going to attempt a "production" deploy, I suggest using a name space, i.e. something like Requires: pkgnamearch(foo) = %{_arch) rather than Requires: foo,%{arch} The reason for using the name space is that it will be easier to verify dependency closure within that "pkgnamearch(...)" syntax, and the intent of the dependency implied by the wrapper is clearer, and less likely to collide with some other dependency. Note that I think the above is not the right thing to do. however, the existing dependencies names can easily be used to achieve your requested goal. rpm-4.4.7 can already verify *runtime* sonames in Provides:. By *runtime*, I mean an soname from a library not in a package, but rather installed through other means, like apt, or "make install", or the native vendor install. The *runtime* dependencies are properly elf32/elf64 colored iirc, certainly can be made so in an hour if I forgot to do that. And, for that class of -devel packages that carry a "foo.so" symlink, rpm-4.4.7 generates a dependency for all symlinks on their end-point automagically. That dependency does not carry elf32/elf64 coloring however. It should be perfectly obvious that none of the above is possible in rpm-4.4.2: UPSTREAM Please add comments to https://lists.dulug.duke.edu/pipermail/rpm-devel/2007-April/002260.html |