Notice: This Wiki is now read only and edits are no longer possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Difference between revisions of "FHS Compliant Packages"
(→Background) |
|||
| Line 2: | Line 2: | ||
During the development of Fedora Core 6 it became nescesary to make the Fedora Eclipse packages | During the development of Fedora Core 6 it became nescesary to make the Fedora Eclipse packages | ||
| − | multilib compatible (see | + | 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 | + | 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. | + | /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. | + | 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== | ==FHS Compliance== | ||
Revision as of 13:09, 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 stage of solving this problem was to make the packages FHS compliant, that is all architecture dependent data was moved from from /usr/share/eclipse to /usr/lib<64>/eclipse/. Symlinks in /usr/share/eclipse pointing to arch dependent data outside of /usr/share/eclipse are also not acceptable.
Thankfully Eclipse supports the notion of an extension location which can hold the arch dependent files outside of its main install directory. We created 'links' directory inside the main install directory which has .links files which reference the paths to the extension locations:
fragments64.link
path:/usr/lib64
fragments.link
path:/usr/lib
Notice we put both the 64-bit and the 32-bit links files in the links directory so that the RCP package would be the same regardless of the arch (required for multilib but not FHS). This works because Eclipse allows .links files that reference extension locations that do not exist therefore users aren't forced to install both the 32-bit and 64-bit packages at the same time.
The the final step to making our extension location was to create a file called ".eclipseextension" file in /usr/lib<64>/eclipse/ to let Eclipse determine if this extension location is compatible with itself. The file looks like this:
.eclipseextension
name=Eclipse Platform id=org.eclipse.platform version=3.2.1
For more details about the various ways to create Eclipse extension locations see this excellent article by Chris Aniszczyk (zx@us.ibm.com), Software Engineer, IBM and Phil Crosby (philc@philisoft.com), Student, University of Maryland, College Park:
http://www-128.ibm.com/developerworks/opensource/library/os-ecl-manage/
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 has an arch specific directory inside it.
- 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.
- 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:
- 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.
- 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 <link>file-extractor utility</link> 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:
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.