Wednesday, May 16, 2012

Making P2 working with RPM - last milestone

Maybe you remember my last post about making P2 and RPM working robustly together. Having the Eclipse Platform M7 packaged in Fedora, and Fedora frozen, I have finally found time to look at that work again.

So, first of all, I was surprised how poor programmer was the past me. Then I have fixed a couple of hardcoded paths, got the solution working again, and even managed to prepare and install my first RPM-wrapped feature into the modified version of Eclipse without breaking the ownership of files.

Ownership of files is a pretty important aspect of Fedora security mechanism - a file installed by RPM into /usr should not be changed because otherwise the verification of system will fail - the system will be believed to be compromised.  P2 changes many files in Eclipse installation if it only is allowed to do so.

After the installation - Eclipse successfully started with my new RPM feature installed. But then I have discovered a hole in my logic. And then my logic appeared to be like a cheese:


I totally forgot about the fact that once I generate a profile from an assembled installation, P2 will start working as usual, and I will not be able to uninstall anything. I'm not sure if you know it, but P2 is an API to control the bundles.info file, which is

only.

P2 does not care if your bundles.info got changed. It will overwrite it.

My attempts to solve that problem made the scope of changes growing very fast. I even created wiki page and put there some things that need to be taken into account.

I'm sorry folks, especially for those haunted by issues similar to:

You will not get a revamped version of P2. I do not think it is possible and I'm officially tossing this idea. You have to be patient - there is no instant cure for those issues. Eclipse Shared Installation works poorly out of the box (see bug 358471), and things get even worse if you take into account additional restrictions that Fedora puts on P2.

In the meantime - what do you think about preventing Eclipse from being run by root by accident?  It is terribly easy to do that on Linux, but then all your dropins stuff goes into master profile and you cannot revert that.

4 comments:

  1. The fact that you can't modify files on disk has been repeated over and over again. Ian and I covered this in our talks at EclipseCon 2011 and 2012. I'm sorry to see that you've spent your time expecting this to work.

    As for making the shared install work nicely with RPM, Andrew O. and I discussed possibilities way back at the beginning of p2 but we never got to complete the work.

    ReplyDelete
    Replies
    1. I have not been there, but if all goes well I may attend ECE :-). Will you be there? I'm interested in picking what was started by Andrew and continuing that work :-)

      BTW. I have not spent my time in vain - I have learned a lot more about P2 - it will serve well while packaging Eclipse bits.

      Delete
  2. I still like the idea of a special Configurator that aggregates bundles.info snippets.

    Sorry you've run into trouble, Chris, but it's probably best that you discover these things yourself instead of me just telling you ;)

    ReplyDelete
    Replies
    1. Actually this still could work if I were able to split each profile xml into a set of xml corresponding to particular locations. Yet another idea to try out!

      Delete