[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [p2-dev] support for 3rd party installers
- From: Krzysztof Daniel <kdaniel@xxxxxxxxxx>
- Date: Thu, 27 Jun 2013 09:36:20 +0200
- Delivered-to: email@example.com
- Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwCAIAAADYYG7QAAAAA3NCSVQICAjb4U/gAAAHIklEQVRYw61YTWwbxxX+SC5FmVr9mCuzNF1KlFFT5GphG1VaJYHSGE4QA+LNhwrJQb32XLg5BT4YaBAkhdGjz0JTQD4YuYiHIjHk2khqIKnlYLUUKcCmvYFD0FqHspcEKS61PbzlcMU/kyIHxGJ3uDvzzffe+96bcVRKBnppVaPq4lx07eadhit7p93nzl7RNA9XNapGSTNKWsO/9nfsPR1WAoDrBgEbwj6WUdIeZ4prqze21ldZ51x8ZXnlz6d/E2z5STfN0cFk7RiuGtWHX9784vrHHcb9618+P7v8ATcstBytA9C2gJiXNLjLzrbawEq7RmydiYbsTDdQ3htDzW1nW726/HZPJri29u2ZaKjd8vpyaqOkra3eQI/t6vLbO9sqcUP0sJu+AFWN6mfXrnew1McfLdmNxa4A1lZvGCWty4m410oO3T/88mZLNHPxlfj4LsO0vjdJrzE0ALbWV3+clX77pw87ENMVIIamalQTKdkOYmt9tQZld31vkmGKj+/GP1oCrEfEVwhfIiWfa9LGozu13ZftlHTTGGf//Oo/rpmZltLasw+9un/P7hzre5PdA2LoH5W5fn2og7sAiIUiSTXd/FosFGnyd3z+r8Sr+/cQ/XAwgBIpeS6+ckXyQfgDAGgyAMyLsXkRPygAkmo6dv4ywgetv1fTRG2/Tm2X/Pj4roUGwLzIewPW/TsBAL/DxeYP9WLWxll6PSWfwx9fO11v2R7hg7Y0NLU66MPO1C+gQ+GQceIITZAAmIELA3Pq+uJs9JgeoVFCyhp1Osqa3WTQ5FgoolQwGIaaF9dgi3YQ2702UB/qpsIqay1NBgDq08EAEgO+7kGYHoF+dZLCBwAc2Y3Kd7dMI9+XD1WNauXmP5RKUAxFaNyWhrAbqzw2Qjeel4eAkmB6XhbKY3Bw! E0cEZBp5C JKoyUolKNbUhWGiuT0vC/Z7eiw8SBo1/QSgVILimxMsSE0jD044CiBaCv/ORdzeRsapZF84shvWis9f5kU/cUNohp8/1YtZ5b/5REqOj+9aOeQHhTCRpu8XIhjrw2QuzlUBdCVXyxjB2PnLSvYFgOTmLWxasIafawB0JZfc/MoBLM1eiAV8CB/w3gBBFAM+aM+SavrsW30XaLzo1+/eFgPS3+/IVyQAPkd2Y31vEpiMj+9Ck/ViPZPEQhGlEkyk5EQK8c0aSQgifICwGBtI2JeNCYqU+PhuUk0nN2+ZgQtLs5b4JtU02YIopPwfH9+9Ivko6UKQRhcWLZUXpKERV78Fmiv3tPAgCUDJvhADPmiypSuanFTTRInVz9q8yHsDZGjys8IvW4SJe/cNyzTDwhFTx77vFMJbAET4eNGvF0Xe6wegKxIzAS/6gYv63dsMjekReLFRpXjRXxpIcuW9Ad4baKFDggRAdD9r4IaBYApJAd+c/o6o1KUTU3b5OZQ47ZlhXmzQayaSFHH1xyNEmX3Pyw0LnuNz+i9bhMn0CDwAkWBJDQmVKROJpKOs0WJKJ6YGkFxpl1k1qvu+U+6haIsSzO7LGaeu5FokVxaqVkqx1HwQBVq7fM6qJU0mTC2n7IDjKOVHs4ToSg6CxIv+0okp0yOQIPGiv9235EPlsZEOzvR6QORMppHfL7TaM2iyruSGnz+1lKbm18Qi43K/UGX0dDZZp/MhwvE4Uww9USh//f5i9FCU2Uvs9sWJruTUafG0x6jsb7uHosRW1T/VW5QRFNqzKgDJf9kwPFy+RcFfq7UPyUENX3Lzlpl98Whh8bQnWkmnK4A7EnH1GvY/rv2bakV1uq4uj8pcjDtkLxIhmlgvZpFxWp3hA9ZJFf5M2GsCbkQAVNJp18xMz6ljdGFRtW3vayRNeLg87w3oyNHqY6GIfvdQBc2LfqLKIkyQxFp1ZZ4EarB6AzS6sMjOGET3s2Q2D! SzS4ipkoD DqFYUgNTsToeG9AT2cdQ9FTcA08sad793vvY/QRM9RFvrfTUd2w5HdoFTFdkJ1C2acVFFYtiOFrBVlDE1tuCkHN+H4+SWAyjdfdyj12zKkVIIIBAFA8KnT4igwE/Y+zhSZt5LJqPKqdfrr/9pyH0m8i3OV0tZpiXHne+7Spd4YIo8ZXVhklBCambDXVnJY0zdEO6Fhud08OUY6wr37hvu99weg1K/u33t1/x4dwT7OFFVTslKs6EfGaQ91ZixCQznfwU1Q/qGb4UuX3JHenZpOx+1nl4Ts7PIHAPQn2RGqdcJUwzsBp44c4ET4YOT4HNsV7ftOscN/ovxMNNQu5gG4rn5ytfVhyk+5Pd/JxsNGLXdq+tzxCfeT/PFjpa2hY/6hY/5fT43sPy9AkyFO8sFfufnpBjR0iJtIyTtabrpU+vmhfCIadHLennVoaVYaXVicCXvZRpPkG5aDS6EHCnkSlbD2mpDQkKV2tlU2YCIlL81Kn127/smnf2s56f8BT1i2ky/8xFYAAAAASUVORK5CYII=
- Organization: Red Hat
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
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.
> 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
> 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 , and opened a bug . 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.
>  http://wiki.eclipse.org/Equinox/p2/Plan/3rd_party_installers
>  378329: Support 3rd party installers
Krzysztof Daniel <kdaniel@xxxxxxxxxx>