FHS Compliant Packages

Background

During the development of Fedora Core 6 it became nescesary to make the Fedora Eclipse packages multilib compatible (see https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=207016 for more details). A set of packages is multilib compatible when all files in /usr/share/ are the same for every package across architectures and builds. Because multilib packages have no architecture dependent data in /usr/share/, they are usually FHS compliant as well. For more information refer to the FHS guidelines http://www.pathname.com/fhs/pub/fhs-2.3.html.

This document is intended for developers from various GNU/Linux distributions who wish to make their Eclipse packages either multilib or FHS compliant.

FHS Compliance

The first step to making the Fedora Eclipse packages multilib compatible was to make the packages FHS compliant. For this compliance we needed to move all architecture dependent data from /usr/share/eclipse/ to /usr/lib{,64}/eclipse/. Putting symlinks in /usr/share/eclipse/ that point to arch dependent data outside of /usr/share/eclipse/ is the same as having arch dependent data inside /usr/share/eclipse/ so this would not be considered a solution.

Thankfully Eclipse supports the notion of an extension location which allowed us to put the arch dependent files outside of the main install directory. A 'links' directory was created inside of the main install directory and .links files that refer to the external extension locations were added:

fragments.link

 path:/usr/lib

fragments64.link

 path:/usr/lib64

Notice that we are using both the 64-bit and the 32-bit .links files. This is because we want the RCP package to be the same for all packages which is required for multilib but not FHS compliance. Users aren't forced to install both the 32-bit and 64-bit packages at the same time because Eclipse allows .links files that reference extension locations that do not exist.

The the final step to making our extension location was to create a file called ".eclipseextension" in /usr/lib{,64}/eclipse/. This lets Eclipse determine if this extension location is compatible with itself.

.eclipseextension

 name=Eclipse Platform
 id=org.eclipse.platform
 version=3.2.1

For more information about the various ways to create Eclipse extension locations see this excellent article by Chris Aniszczyk and Phil Crosby:

http://www-128.ibm.com/developerworks/opensource/library/os-ecl-manage/

Specific Details

Here is a list of plugins, fragments and features that needed to be moved to /usr/lib{,64}/eclipse/{features,plugins} for FHS compliance:

• org.eclipse.swt.gtk.linux.x86_3.2.1.v3235.jar
  • The SWT fragment is arch-dependent because the Java source in SWT is preprocessed to use ints on 32-bit platforms and longs on 64-bit platforms. Also, the SWT fragment includes its JNI libraries.

• org.eclipse.core.filesystem.linux.x86_1.0.0.v20060603.jar
  • This fragment includes native JNI libraries.

• org.eclipse.update.core.linux_3.2.0.v20060605.jar
  • This fragment includes native JNI libraries.

• org.eclipse.platform.source.linux.gtk.%{arch}_3.2.1.r321_v20060921-MGDh_08KUYM-Bvn
  • This fragments is arch dependent because of its name and because it contains an arch specific directory.

• org.eclipse.rcp.source.linux.gtk.x86_3.2.1.r321_v20060801-clWbqCmjexIWDqg
  • This fragment has the SWT JNI source code which is generated to use ints on 32-bit platforms and longs on 64-bit platforms making it platform dependent.

• org.eclipse.platform.source_3.2.1.r321_v20060921-MGDh_08KUYM-Bvn
  • This plugin contains src/org.eclipse.platform_3.2.0.v20060601/launchersrc.zip which has platfrom specfic code because we set osgi.sharedConfiguration.area to /usr/lib{,64}/eclipse/configuration.
  • TODO It would be nice if the launcher source zip could be removed from this plugin and/or the patch could be made in such a way that it would not produce arch-dependent source code - I realize this may not be possible though.

Besides moving plugins and features out of /usr/share/eclipse we also had to:

(1) move the binary launcher to /usr/bin/eclipse

• Our packages previously had a symlink from /usr/bin/eclipse to /usr/share/eclipse/eclipse which in turn had a symlink to /usr/lib{,64}/eclipse. We carried a patch which enabled these symlinks to work. With this set of changes we created a patch to the binary launcher which allows it to find startup.jar in /usr/share/eclipse/. The patch hard codes /usr/share/eclipse/startup.jar so you'll have to use sed to change this value to the correct location if you are not installing eclipse in /usr/share/.

(2) and set the osgi.sharedConfiguration.area java property to /usr/lib{,64}/eclipse/configuration

• The osgi shared configuration area contains the JNI shared libraries that have been extracted with the file initializer utility therefore it needs to be set to /usr/lib{,64}/eclipse/configuration. To do this, we manunally set the osgi.sharedConfiguration.area java property in the binary launcher using sed to set the value to /usr/lib or /usr/lib64 depending on the arcitechure wordsize of the current build.

Both of these changes can be found in this patch:

http://cvs.fedora.redhat.com/viewcvs/devel/eclipse/eclipse-launcher-set-install-dir-and-shared-config.patch

TODO It would be nice to re-work this patch so that it could be applied to the standard launcher code.

Multilib Compliance

Here is a list of plugins and features that needed to be moved to /usr/lib{,64}/eclipse/{features,plugins} for multilib compliance:

• com.ibm.icu_3.4.5.jar and com.ibm.icu.source_3.4.5
  • The resource files (.res) are generated in different orders on different architechures.
  • TODO This should be investigated and fixed so that these plugins can move back to /usr/share/eclipse/plugins. However, if the icu4j build is removed from the Eclipse package and Eclipse merely requires the icu4j plugins, this probem should go away.

• org.eclipse.platform.doc.isv_3.2.1.r321_v2006030.jar
  • The HTML of the javadocs in this plugin are generated differently on different architectures therefore multililb conflicts are present if this plugin is included in /usr/share/eclipse/.
  • TODO This problem needs to be investigated and fixed so that this plugin can move back to /usr/share/eclipse/plugins/.

• org.eclipse.help.webapp_3.2.1.R321_v20060803
  • WEB-INF/web.xml is generated differently on different architectures therefore multililb conflicts are present if this plugin is included in /usr/share/eclipse.
  • TODO This problem needs to be investigated and fixed so that this plugin can move back to /usr/share/eclipse/plugins/.

• The org.eclipse.sdk feature and plugin have been moved to /usr/lib{,64}/eclipse/
  • To ensure that the eclipse.product is set to org.eclipse.sdk.ide in config.ini when eclipse-sdk is installed, we must check for its presence at package installation time (this means %%post{,un} in the RPM case). This does not work in the biarch case, though, if it is not in an arch-specific location. This results in complaints that the sdk plugin is found twice, but this is better than always appearing in the about dialog as the Eclipse Platform with the platform plugin version number instead of the actual SDK version number.

Besides moving these plugins and features to /usr/lib{,64}/eclipse/, we also needed to repack all of the jars and zips (including the jars and zips within these jars and zips). This is needed so that a consistent timestamp can be set on the contents of the jars and zips giving them the same md5sum across builds.

• A script which repacks all the jars is run after every RPM build in Fedora but it currently doesn't support zips or jars within jars. To work around these deficiencies, we manually repack the zips and jars in the eclipse spec file at the end of %install.
• TODO A proper solution to this problem would be to write an application that re-writes the timestamps directly on the zip file or jar with out uncompressing it. This application would would only need to uncompress entries that were themselves zips so that it could re-write the timestamps.

Issues

Moving the platform dependent files from /usr/share/eclipse/ to /usr/lib{,64}/eclipse causes these issues:

1. The Product Configuration manager thinks that these 4 fragments are missing.
2. It's possible for a user to disable the extension location and therefore disable all those fragments. The next time the user starts Eclipse, it doesn't work because it can't find the swt fragment. The user must delete their configuration (i.e. 'rm -rf ~/.eclipse') to get Eclipse to start again.

See https://bugs.eclipse.org/bugs/show_bug.cgi?id=162798 for more information.

• TODO Fix this bug.

Authors

Andrew Overholt <overholt@redhat.com>, Senior Software Engineer, Red Hat, Inc.
Ben Konrath <bkonrath@redhat.com>, Software Engineer, Red Hat, Inc.