Difference between revisions of "FHS Compliant Packages"

Revision as of 13:33, 4 December 2006

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 (see the Multilib Compliance section #Multilib_Compliance for more details. 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 now that

    we are setting osgi.sharedConfiguration.area to be /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.

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 was 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 will allow it to load startup.jar from /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.

1. 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-extractor utility http://dev.eclipse.org/viewcvs/index.cgi/equinox-incubator/org.eclipse.equinox.initializer/ 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.

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 will 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 architures therefore

  multililb conflicts are present if this plugin is included in /usr/share/eclipse.

TODO: This needs to be investigated and fixed so that these plugins can move back to /usr/share/eclipse/plugins.

• org.eclipse.help.webapp_3.2.1.R321_v20060803

-> WEB-INF/web.xml is generated differently generated differently on different architures therefore

  multililb conflicts are present if this plugin is included in /usr/share/eclipse.

TODO: This needs to be investigated and fixed so that these plugins 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 %%post{,un} time.  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{,lib}/eclipse, we also needed to repack all of the jars and zips (including jars and zips within other jars and zip) to set a consistent

 timestamp. 

-> A script which repacks all the jars is run after-ever build but it currently doesn't support zips or jar and zips

  within other jars and zips. To work around these deficiencies, we manually repack the zips and jars in the eclipse spec file.

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

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.