Bug 216025 - RFE: include arch in package requirement resolution
Summary: RFE: include arch in package requirement resolution
Status: CLOSED DUPLICATE of bug 235755
Alias: None
Product: Fedora
Classification: Fedora
Component: rpm   
(Show other bugs)
Version: 6
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Paul Nasrat
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 2006-11-16 20:15 UTC by Ben Konrath
Modified: 2007-11-30 22:11 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2007-08-10 07:02:06 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description Ben Konrath 2006-11-16 20:15:50 UTC
In order to solve bug #207016, we had to make the Eclipse packages multilib
compatible. When we did this we noticed that rpm did not include the arch when
resolving the package requirements. For example, libswt3-gtk2.ppc would satisfy
a requirement for libswt2-gtk2 on the eclipse-rcp package when we installed
eclipse-rcp.ppc64. This is incorrect because the libswt3-gtk2 package is arch
specific and Eclipse will not work when the SWT package does not have the same
arch as the rest of the Eclipse packages. To get around this, we put a
dependency on an arch specific file in the libswt3-gtk2 package which ensures
that the correct SWT package will be installed. It would be nice if rpm would
include arch when resolving the package requirements so we don't have to include
this type of file level dependencies. Thanks.

Comment 1 Paul Nasrat 2006-11-17 09:20:26 UTC
For libraries rpm automatically detects 64 vs 32 bit for automatic provides on
ELF, so if eclipse-rcp links against libswt3-gtk2.so.N it will do the right
thing (32-bit) or will have libswt3-gtk2.so.N(64-bit) requirement satisfied by
64 bit package.  Why was the normal behaviour not sufficient?

Comment 2 Ben Konrath 2006-11-22 17:04:42 UTC
What you describe is not working because the swt shared libraries are not linked
 to anything in eclipse-rcp. This is because they are JNI libraries which are
statically loaded by the swt bytecode. Also, the swt byte code is arch specific
because it is pre-processed to use int or long depending on the word size. For
this reason we had to move the swt jar and the JNI libraries out of

Perhaps this is a unique case that shouldn't be supported automatically. Feel
free to close the bug if you agree. Thanks for the explanation.

Comment 3 Jeff Johnson 2006-11-23 15:23:10 UTC
If there are per-arch JNI dependencies, then a provides dependency extraction
is likely trivially automated, all that is needed is deciding on a conventional
representation like (I'm not proposing this representation, merely illustrating)
    Provides: java(jniarch) = i386

Automating java/jni requires extraction is likely harder, but all you're asking for is
syntax for representing arch in dependencies, that would be achieved by
manually adding to a spec file
    Requires: java(jniarch) = i386

FWIW, the manually added dependencies mentioned in #1 "work" as well, just a different conventional 

Comment 4 Ben Konrath 2006-11-29 21:47:34 UTC
If the file level dependencies I added are considered correct, I'm OK with
leaving things as is and closing this bug. However, if you think it would be
useful to add a convention for representing jni libs, I would use it.

Comment 5 Jeff Johnson 2006-11-30 03:54:52 UTC
Depends on what you want. An hours worth of scipting could automate the mess, mebbe another hour to 
wire into rpmbuild. But file deps manually added "work" too.

Comment 6 Jeff Johnson 2007-04-11 11:34:14 UTC
Please add comments to


Comment 7 Panu Matilainen 2007-08-10 07:02:06 UTC

*** 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.