Bug 212523 - rpmbuild lets x86_64 packages satisfy BR's when building for i386
rpmbuild lets x86_64 packages satisfy BR's when building for i386
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: 2006-10-27 04:23 EDT by Hans de Goede
Modified: 2007-11-30 17:11 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2007-07-18 15:04:13 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 Hans de Goede 2006-10-27 04:23:46 EDT
The summary says most of it, when doing an rpmbuild --target=i386 I
don't want libXt-devel.x86_64 to satisfy a BR: libXt-devel .

I know things aren't that easy because with something like BR:
desktop-file-utils, the x86_64 version will do fine.

Suggestion: make rpmbuild check the arch of BR's who's name ends with

That would catch most cases except there where a package isn't named -devel but
must be of the exact arch. These exceptions could then be fixed at the packaging
level by making the required package Provide a -devel (even if 100% Virtual) and
then BR package-devel.
Comment 1 Jeff Johnson 2006-10-27 08:22:43 EDT
There's nothing stopping you from adding arch-specific dependencies to existing dependencies.

   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 ..."
Comment 2 Jeff Johnson 2006-10-27 08:28:35 EDT
Sorry, I left out " ... -- Requires: %{name}.%{_arch} might also be automated transparently in spec files ..." 
in the sentence above.
Comment 3 Hans de Goede 2006-10-27 08:35:42 EDT

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}
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
Comment 4 Jeff Johnson 2006-10-27 10:28:31 EDT
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:


Comment 5 Jeff Johnson 2007-04-11 07:39:53 EDT
Please add comments to

Comment 6 Panu Matilainen 2007-07-18 15:04:13 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.