On 10/26/2011 09:20 AM, sami wagiaalla wrote:

To add support for this in your eclipse package you have to add the following line to your rpm spec file:

%_eclipse_pkg [package name]

For what Fedora versions is this applicable to?

On Wed, Oct 26, 2011 at 11:20:46AM -0400, sami wagiaalla wrote:

Hi,

The way we currently install Eclipse plugins in Fedora is incorrect and somewhat fragile.

RPM places all the plugin artifacts in the proper directories. However that does not update the eclipse metadata. This means that until the next time eclipse starts it is unaware of the newly installed plugins.

Because the user would normally run Eclipse not as root Eclipse does not have permission to write to the meta data files located in the installation directory. It therefore creates a parallel version in the user's home directory ~/.eclipse. This creates a fragile installation and leads to a whole host of problems.

To improve this I have written apatch which runs the Eclipse reconciler during rpm installation. The Eclipse reconciler is an Eclipse application which goes through and checks the installation directories and updates the eclipse metadata with any newly installed plugins.

To add support for this in your eclipse package you have to add the following line to your rpm spec file:

%_eclipse_pkg [package name]

Here is an example from the eclipse-rse spec file for the eclipse-rse-sdk rpm:

%package sdk [...] %_eclipse_pkg sdk

The above macro expands to the following:

%post sdk touch /var/run/eclipse/run-reconciler

%postun sdk touch /var/run/eclipse/run-reconciler

if [ $1 == 0 ]; then eclipse-reconciler.sh fi

%posttrans sdk eclipse-reconciler.sh

I apologize if you have experienced instability in Eclipse installations on rawhide, it is probably due to these changes. Please let me know if you have any comments questions or suggestions.

I will be filing a request to update the Eclipse packaging guidelines.

Yes please. One note, I don't like macros that span multiple scriptlets. Having a macro for each scriptlet (or forgoing a macro if the resulting code is simple enough) seems to be about the right level of indirection.

-Toshio

On 11/01/2011 10:56 AM, sami wagiaalla wrote:

...

[...] One note, I don't like macros that span multiple scriptlets. Having a macro for each scriptlet (or forgoing a macro if the resulting code is simple enough) seems to be about the right level of indirection.

It does not look pretty I agree, but my motivation is to make things simple for plugin packagers. Also, it makes it simple to update the macro when bugs show up without having to update the packages with additional macros. They just get the update when they are rebuilt.

Hi Toshio,

I hope you are OK with the above. I will be requesting an update to the guidelines soon.

(https://fedorahosted.org/rel-eng/ticket/5021) so I will send out the message as soon as that is approved. The goal is to finish this before f17 branches from rawhide.

Unfortunately I have missed the above deadline but here is an update of I have been upto:

Before the custom tag was created I started patching the packages and finished all of them.

I have posted the rpms here:

http://people.redhat.com/swagiaal/reconciler/

The above is a yum repo for which the repo file is here:

http://people.redhat.com/swagiaal/reconciler.repo

All the patches can be found here:

http://people.redhat.com/swagiaal/reconciler_patches/

Please give the packages a try. I have done some smoke testing. Basically I just looked to see that the bundles provided by the given package are loading. Things look good. Because we missed the branching dead line these patches will have to be committed to both rawhide and f17. An update will need to be pushed to f17. I have requested permissions to most of these packages but if you are interested in doing the work yourself please reply to this email with the packages that you want to take care of. Otherwise you might see an email from me requesting commit permissions to your packages.

So let's give these packages a couple of days and start (hopefully also finish) committing by Monday.

Here is a summary of packages:

Broken build:

eclipse-anyedit (Does not build possiblly because of use of internal classes) eclipse-collabnet-merge (https://bugzilla.redhat.com/show_bug.cgi?id=786583) eclipse-m2m-qvtoml (https://bugzilla.redhat.com/show_bug.cgi?id=786943) eclipse-mdt-uml2 (https://bugzilla.redhat.com/show_bug.cgi?id=786933) svnkit (Does not build. Java errors) eclipse-wtp-servertools (Does not build) eclipse-wtp-sourceediting (does not load because of some unsatisfied requirements)

Retired:

eclipse-demos eclipse-nlspackager eclipse-sdk-nls eclipse-slice2java

Done:

eclipse-changelog eclipse-fedorapackager eclipse-mylyn eclipse-mylyn-builds eclipse-mylyn-commons eclipse-mylyn-context eclipse-mylyn-docs eclipse-mylyn-ide eclipse-mylyn-tasks eclipse-mylyn-versions eclipse-rpm-editor eclipse-rpmstubby eclipse-emf eclipse-rse eclipse-cdt eclipse-jgit eclipse-egit eclipse-birt eclipse-callgraph eclipse-gef eclipse-oprofile eclipse-systemtapgui eclipse-valgrind eclipse-linuxprofilingframework eclipse-testframework eclipse-vrapper eclipse-eclemma eclipse eclipse-cdt eclipse-emf-query eclipse-emf-transaction eclipse-emf-validation eclipse-epic eclipse-avr eclipse-checkstyle eclipse-cmakeed eclipse-dltk eclipse-dtp eclipse-eclox eclipse-findbugs eclipse-gcov eclipse-gprof eclipse-manpage eclipse-mdt-ocl eclipse-mercurial eclipse-moreunit eclipse-mpc eclipse-nls eclipse-p2-discovery eclipse-packagekit eclipse-phpeclipse eclipse-ptp eclipse-pydev eclipse-quickrex eclipse-setools eclipse-shelled eclipse-slide eclipse-subclipse eclipse-texlipse eclipse-veditor eclipse-wtp-common findbugs-contrib

I am going to hold off on this as I have run into an issue where bundles installed using and update site don't work with bundles installed using rpm if there is a bundle conflict between the two.

I am investigating.

After looking into this I realized that we cannot move forward with the reconciler solution.

The issue here is not the old issue of plugins not being installed properly using eclipse's installation system p2, but having plugins installed in two different locations each with it's own metadata. The first location being system directories used by rpm such as /usr/share/eclipse/ and the location used by the eclipse installation system ~/.eclipse. When there is a conflict between the two location eclipse simply picks the system installation resulting in the downloaded plugin and all downloaded plugins to be dropped.

We are working on a better solution for this problem.

Thanks, Sami