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.
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?
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.
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
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.
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.
Please add comments to
*** This bug has been marked as a duplicate of 235755 ***