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: [email protected] [mailto:[email protected]] 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 <[email protected]>
Red Hat
_______________________________________________
p2-dev mailing list
[email protected]
https://dev.eclipse.org/mailman/listinfo/p2-dev
_______________________________________________
p2-dev mailing list
[email protected]
https://dev.eclipse.org/mailman/listinfo/p2-dev
