Bug 216025

Summary:	RFE: include arch in package requirement resolution
Product:	[Fedora] Fedora	Reporter:	Ben Konrath <ben>
Component:	rpm	Assignee:	Paul Nasrat <nobody+pnasrat>
Status:	CLOSED DUPLICATE	QA Contact:
Severity:	medium	Docs Contact:
Priority:	medium
Version:	6
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-08-10 07:02:06 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 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
/usr/share/eclipse/. 

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

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

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

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


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