Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [p2-dev] RPM-P2 integration - new approach 
Hi Chris, 

I looked at the proposal. Are you suggesting that each RPM delivering plugins will deliver alongside with the various jars, a bundles.info and some metadata (what you call profile?) and then those files would be logically merged at runtime, or are you suggesting that RPM appends content to the bundles.info and the profile file?
For this last one, I agree that it is simpler since probably no p2 code changes should be required. If we are talking of the first one, then I think it is very involving because you would have to change or create specific versions of simpleconfigurator, simpleconfiguratormanipulator and the profile registry.
 
Since I'm not sure here a more thorough description of ideas we discussed in the past: the droplet and the dynamic creation of profiles.

-=-= Droplet =-=-
I liked the idea of droplet but the fact that you were trying to modify the dropins and reconciler was the main pb to me. I see droplets as another mechanism to install software, mechanism that is complementary to the many other ways that we already have.
For me a droplet would look like this on disk:
   CDT/
       features/
        (features in ready to run format)
       plugins/
        (plugins in ready to run format)
       content.jar
       artifacts.jar
       toInstall.txt

Where the "toInstall.txt" file lists the IU Id of the IU(s) that must be installed.

The RPM installer would store the droplet (e.g. the CDT folder) in a "droplet" folder in the Eclipse platform.
Then at runtime, the droplet bundle would start (before the dropins) , find all the toInstall.txt file resolve those against the profile of "the base" (the read only install of the platform) and proceed with the install, which ends up creating a new profile (Note that since the RPMs are expected to provide all the necessary dependencies, then the install could not fail). After that the migration logic would kick in to find that things have been changed and would propose to reinstall what was in the user space. Btw I honestly never understood the 
To me this solution seems simple because it just acts as another mechanism to install bundles, it is relatively separate from the rest of p2 and the only change that I could foresee to be needed would be something in the shared install mechanism.
Of course implemented like this, this mechanism would only be useful for the case at end (where the droplets are installed by an installer against an existing base that is read-only) but after all this is what we need. To make it usable by everybody (e.g. a normal user adds things through droplets), then the creation of the request would have to be more complex to deal with the removal from droplets of items that could have been depended upon by items installed by the user.

-=-= dynamic profile creation =-=-
Since the "structured" nature of p2 with the bundles.info, the sources.info and the profile file is not playing well with RPM, we had discussed the possibility of having a more dynamic setup for p2 and also the discovery of bundles (which could solve the issue of versions of files being updated for security updates).
The first thing to change would be to replace (or extend) simpleconfigurator and bundles.info by a new mechanism that finds bundles in known places. For example simpleconfigurator could be changed to traverse folders when it encounters one but also be able to deal with files like it does today.
The second thing would be for the profile to never be stored but always recomputed when requested.  This generation of the profile would be done from bundles info but also other sources like feature, or whatever we want to provide it. In this specific case, since the base is not modifiable then the metadata for the things that are from the base does not need to be precise (e.g. no need for the touchpoint actions) since the IUs from the base will never be uninstalled by p2 itself. If precision was something necessary, then we could have a storage of 

So how does that fit together:
The platform is shipped with a bundles.info that points to places where the bundles can be found, and no profile.
When a new RPM is installed, it appends a line to the bundles.info file to say where its bundles are located (and something similar is done for features or more generally metadata). At runtime, when the profile is requested, a profile is created from this data and returned.

Though in appearance a bit more complex than Droplets seem to solve all the RPM related problem, but would also be generally applicable to start provisioning with p2 any Equinox based app w/o having to ship a profile.

Let me know what you think,

Pascal
-----Original Message-----
From: p2-dev-bounces@xxxxxxxxxxx [mailto:p2-dev-bounces@xxxxxxxxxxx] On Behalf Of Krzysztof Daniel
Sent: October-22-13 3:56 AM
To: p2-dev
Subject: [p2-dev] RPM-P2 integration - new approach

Hey,

I've described a new approach to the problem [1]. It consists mostly of advices I got in the past, but now it seems to make sense as a whole :-). Also, it looks like being much simpler to implement, and much less invasive.

Comments welcome, as always.

[1]
http://wiki.eclipse.org/Equinox/p2/Plan/3rd_party_installers_on_Linux#Solution_description_II

--
Krzysztof Daniel <kdaniel@xxxxxxxxxx>
Red Hat

_______________________________________________
p2-dev mailing list
p2-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/p2-dev

Back to the top