Re: [p2-dev] support for 3rd party installers

[Krzysztof Daniel <kdaniel@xxxxxxxxxx>]

On Wed, 2013-06-26 at 17:28 +0200, Mikhail Kalkov wrote:
> Hi Daniel,

First of all, thanks for your response!

> I am responsible for maintaining couple Eclipse installations in my organization, and this organization wants me to make it possible to version-control Eclipse configuration so that depending on the currently checked out label a different set of bundles is loaded. Right now this is solved by installing several base Eclipse instances onto a read-only network drive, and supplying often-updated bundles via the dropins mechanism. So, depending on the checked out label, the correct paths to a base installation as well as to a set of dropins and to user configuration area are selected. The immediate drawbacks are the need to create a new base installation if any bundle in it has to be updated, the need to script migration of settings between user configareas, and the need to deploy 40+ bundles via dropins.
> 
> From your description it sounds like droplets may take place somewhere between p2 bundles installed into the shared area and dropins installed into the user area. If I understand correctly, they will be packaged already in runnable form, installed by administrator and respond to changes when run by user. There are some things I didn't get though.
>  - What exactly should and should not be packaged into a droplet? For example, will bundles in runnable form be accompanied by configuration files?
>  - Would there be mechanism to check if installed droplet is p2-compatible with target Eclipse installation or do you think it's responsibility of packager to ensure compatibility?
>  - What exactly should happen during droplet (un-)installation? Assume that I have Eclipse Classic installed and would like to install PlantUML, which is packaged as a separate droplet (RPM). How would Eclipse Classic know that it has got a new droplet? Would there be a droplets directory that is checked upon startup? Can a droplet be installed solely by copying files around without updating them?
>  - What exactly should happen at start up time apart from p2 remediation of the new base+droplets platform against user-installed plugin? Are any droplet configuration files going to be merged into user config?

My intention was to have a group of plugins/features installed together
as one unit (all or none go in). I have not yet considered configuration
files.
Regarding overall droplets management I'd expect following things:
* during startup droplets are merged with the base installation. Users
see them as a part of the master installation.
* unresolved droplets report an error (they are supposed to work, it's
not a best-can-do approach like in dropins).
* uninstalled droplet is seen as a base installation change. user
configuration area is dropped and then reinstallation dialog kicks in,
which restored things that user had installed.
* from an administrator point of view - it would be all about
copying/deleting files into appropriate directories.

> Overall, I think your idea sounds interesting because it may let me
>  a). minimize the base Eclipse installation and check it into a version control system (it's too big and thus changes too often). This is similar to your packaging plans.
Agree.
>  b). speed up the first Eclipse start up by skipping the p2 installation step required for dropins to work. I guess you'd benefit from it too.
You may be disappointed here. I don't see a way to install anything
without using p2, so it is quite possible the first startup will be
equally long.
>  c). separate packaged bundles from user-installed ones. You've mentioned that as one of the goals too.
> In this light, leaving out touchpoints and even possibly configuration files sounds like an acceptable sacrifice.
What are your usecases for touchpoints and configuration files?


> Kind regards, 
> Mikhail Kalkov 
> 
> Purple Scout AB 
> Software Developer
> 
> 
> ----- Original Message -----
> From: "Krzysztof Daniel" <kdaniel@xxxxxxxxxx>
> To: "p2-dev" <p2-dev@xxxxxxxxxxx>
> Sent: Wednesday, June 26, 2013 2:07:46 PM
> Subject: [p2-dev] support for 3rd party installers
> 
> Hello P2 masters,
> 
> Eclipse installation in Fedora (managed by RPM, shipping in 7 days) was
> broken every time after Eclipse was built. Heavy work happening in the
> shared and remediation areas made my patches highly unstable, and I'm
> tired of it - maintaining my own set of patches is *very* time consuming
> (not to mention that fixing one problem reveals others).
> 
> So I'd like to have support for 3rd party installers in Luna.
> 
> The rationale is quite trivial: in the devops times centralized
> deployment is something that completes common build infrastructure. One
> has to have the possibility to quickly build and deploy Eclipse and
> Eclipse components to developers. It's just too expensive to let them
> download each new version :-).
> 
> I've put my requirements in a wiki page [1], and opened a bug [2]. I'm
> willing to do the work. If someone else is interested in the solution -
> please speak up - I want this solution to be generally usable, not just
> a niche Fedora solution.
> 
> 
> [1] http://wiki.eclipse.org/Equinox/p2/Plan/3rd_party_installers
> [2] 378329: Support 3rd party installers
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=378329
> 


-- 
Krzysztof Daniel <kdaniel@xxxxxxxxxx>
Red Hat