Creating noarch packages with arch-specific dependencies.

If you look at Eclipse package, you will notice that despite being written mostly in Java, it is arch-specific, and therefore it is installed either into /usr/lib/eclipse/ or /usr/lib64/eclipse/. This is because Eclipse contains a few platform specific libraries  - and SWT is the most important of them. Don't get me wrong - SWT is not just the platform specific library, it is also a common JAVA API to create application that look like native on Windows, Linux and MacOs despite using the same code base.

This is very problematic for Fedora packaging, because any Eclipse plugin depending on SWT and not containing any native code is a noarch plugin, and it should be located in a noarch directory (/usr/share/eclipse).

There is no problem during runtime, because when you start an arch-specific eclipse, it can always locate the noarch directory and load all plugins that are there.

But compilation is a problem, because in many cases you just need the SWT API on classpath to compile Eclipse plugin and two most important arch-specifc macros, %{_libdir} and %{_isa}, are banned from being used in noarch packages, and they will not point you to the right SWT installation?


There are three possible solutions:

• Use Tycho. Tycho is a wonderful Maven extension that makes building of Eclipse plugins easy. 
• Use eclipse-pdebuild script. This script is located in %{_bin} folder and it automagically discovers where is Eclipse (and SWT) installed.

• At this point you should go back and reconsider the two previous bullets. I do not recommend any other build system (especially pure ant) for building Eclipse plugins. However, if you have to, you can always use a magic command ${build-classpath swt}, which will locate the swt.jar, instead of hardcoding a path to it.

Warning:
You should be very very careful when you are using any arch-specific things in a noarch package, especially if you don't know the build system by heart. The risk is that some arch specific path may find its way into the code as a constant, search path or something similar, while the package will be installed as a noarch one. As a result, it will work only on one architecture, and debugging will be very difficult.

This blogpost is based on a clarification request regarding the use of %{_libdir} in noarch packages.