Bug 212523

Summary: rpmbuild lets x86_64 packages satisfy BR's when building for i386
Product: [Fedora] Fedora Reporter: Hans de Goede <hdegoede>
Component: rpmAssignee: 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
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
-devel.

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 12:22:43 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 ..."


Comment 2 Jeff Johnson 2006-10-27 12:28:35 UTC
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 12:35:42 UTC
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?


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



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

    https://lists.dulug.duke.edu/pipermail/rpm-devel/2007-April/002260.html

Comment 6 Panu Matilainen 2007-07-18 19:04:13 UTC

*** This bug has been marked as a duplicate of 235755 ***