Hi Andrew,

Last week I started looking into making our eclipse packages mulitlib compatible to solve bug # 207016 and I thought I'd write up a little status report of what I found.

Here are the issues we need sort out:

1) Ensure the src zips are the same for all arches 2) Put the native fragments in %{_libdir} - the swt classes need to go there too because they use 32-bit or 64-bit references depending on the arch 3) Ensure that configuration will work when the user has different 32-bit features and 64-bit features installed (e.g. 32-bit platform and jdt with 64-bit platform, jdt and pde)

Solutions:

1) ensuring the src zips are the same for all arches ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

- Repack all the zips at the end of the build similar to how the brp script repacks all jars OR - Make the non-arch dependent packages noarch so that the src zips will come from same package on all arches. IIRC the kernel has a hack to do this for its doc package

2) Putting native code in %{_libdir} ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

This site explains how to configure eclipse to put features and plugins in separate directories:

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

The only method that works for SWT is the one that requires the user to add an extension location in the configuration manager. Obviously this is not useful for a build, but we may be able to take the configuration it adds to configuration/org.eclipse.update/platform.xml and insert it in the build.

With this we will need to have configuration/org.eclipse.update/platform.xml and we cannot remove like we have been planning. So we can either use the rebuild features script again or we can run the file initializer with an empty configuration every time an eclipse package is installed. For the file initializer solution I'm not sure if this will preserve section of platform.xml that specifies the separate location of the native fragments. I still need to test this out.

As far as using the rebuild features script again, we have already seen that using it is not really maintainable because it's difficult to know what format the platform.xml file needs to be in. Also, we shouldn't create procedures that require us to maintain code outside of the upstream code. We already spend most of our time packaging stuff and don't have time to respond to real bug reports in a timely manner. Adding this again would just tie us up even more and would be a bad decision IMHO. But if there's no other method that will work, then we have no choice.

3) Working with different 32 and 64 bit features ================================================

We will need to drop the sed logic that changes configuration/config.ini and always run with eclipse.product=org.eclipse.platfrom.ide or eclipse.product=org.eclipse.sdk.ide because both the 64-bit packages and the 32-bit packages will change that config entry. If the two sets of packages get out of sync, this will be set incorrectly.

The solutions for problem 2 might might also cause problems here if the packages get out of sync. Here's an example:

If a user has both the 32-bit eclipse-sdk and the 64-bit eclipse-sdk package installed and then removes the 64-bit eclipse-sdk and eclipse-pde, the 32-bit eclispe-sdk and 32-bit eclipse-pde will not be removed and the pre-configuration will not be set correctly because the packages share configuration directory. I think this would be a problem for both the rebuild features script and the file initializer solution.

I don't really have a solution for this problem. Andrew, do you have any thoughts? If we could specify a different configuration directory, we would be able to get around this, but I haven't run across any way to do this yet.

Ok, that's all I have for now. I'll continue working on this.

Ben