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 /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.
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.
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 https://lists.dulug.duke.edu/pipermail/rpm-devel/2007-April/002260.html
*** This bug has been marked as a duplicate of 235755 ***