Hi,

We'd like to enable an RPM script that mirrors OSGi Require-Bundle, Import-Package, and Export-Package statements into RPM virtual Requires and Provides [0]. While testing this, Alphonse van Assche discovered that our eclipse-ecj package should actually Require eclipse-rcp [1]. eclipse-rcp also includes SWT which itself needs a bunch of GNOME libraries and XULRunner. I don't think we want java-gcj-compat dragging in XULRunner and a bunch of GNOME libraries.

Therefore, I think we need to have a separate ecj SRPM/RPM [2]. I have whipped up a simple one for use by java-gcj-compat and put it here:

http://overholt.fedorapeople.org/ecj-3.4.2-1.fc10.src.rpm

The java-gcj-compat maintainers will have to own it and therefore test it out. I don't anticipate any issues, but please test it ASAP so we can deal with any fallout. Once it's been deemed acceptable, it will have to go through a review which I probably shouldn't do :) Then, the eclipse package will need to:

- remove all references to ecj - keep jdtcore symlinks but not ecj symlinks - move jdtcore symlinks to -jdt package and remove -ecj package

This is all pretty minor and can be done very quickly. Ideally we'd get it done before the beta freeze on Tuesday. If we can't get it done by then, we could perhaps justify the minor changes for after the freeze or wait until F-12.

Thanks,

Andrew

[0] Having automatic and correct OSGi bundle-level requirements matched in our RPMs will be very nice. We will obviously still need BuildRequires but we'll know at install time if there will be an error with OSGi dependency resolution at runtime.

[1] This is because our eclipse-ecj package contains the org.eclipse.jdt.core plugin which needs org.eclipse.core.runtime among other stuff and core.runtime is in the RCP feature. Note that the new ecj package will contain just the batch compiler part of jdt.core -- as opposed to the entire thing like we do now -- so it won't have the dependency on any RCP bundles at the OSGi level (in fact, it won't even be an OSGi bundle).

[2] There are other benefits to a standalone ecj SRPM, of course:

- we don't need to patch org.eclipse.jdt.core and diverge from upstream - GCCMain -- the gcj driver for ecj -- can go into the ecj JAR and not jdt.core itself - bootstrapping a full gcc SRPM no longer requires the output of building an eclipse SRPM

One concern is that RHEL-5 has an unversioned Obsoletes/Provides on "ecj" which should probably get fixed.