Stepping back from how you have implemented your solution, could you please describe what is the problem you are trying to solve and what are the issues with
what p2 is currently able to do?
Iâm asking because in Kepler, Ericsson funded significant improvements to p2 to make sure that changes to the base (what is read only) are not causing the loss
of the plugins installed by the user (see
âdetection of shared install changedâ
http://download.eclipse.org/eclipse/downloads/drops4/R-4.3-201306052000/news/eclipse-news-part1.html ) and Iâm curious to see if that help solve the problems you are encountering.
From: p2-dev-bounces@xxxxxxxxxxx [mailto:p2-dev-bounces@xxxxxxxxxxx]
On Behalf Of Mikhail Kalkov
Sent: July-31-13 8:15 AM
To: P2 developer discussions
Subject: Re: [p2-dev] 3rd party installers, droplets, etc
I'll refrain from technical comments since I'm not that good in p2 internals, but will comment on the problem description.
I think Pascal is right that ability to replace a part of base installation
without affecting other parts would benefit Linux package managers. However, I think the actual user group for this feature is wider, and includes anybody willing to version-control parts of Eclipse. This is pretty much the case for any centrally managed
installation, even on Windows.
Right now it is only possible to version control Eclipse installation as a whole (i.e., "single package"), so one has to create a new installation for each new bundle version. However this approach does not scale because each complete installation is quite
large, and due to a large number of bundles, new installations have to be created too often. Therefore, one is forced to fallback to using dropins (i.e., one "base package" + several "bundle packages"), which are very fragile and the use of which is discouraged.
"Pascal Rapicault" <pascal@xxxxxxxxxxxxx>
Till: "P2 developer discussions" <p2-dev@xxxxxxxxxxx>
Skickat: onsdag, 31 jul 2013 11:50:11
Ãmne: [p2-dev] 3rd party installers, droplets, etc
(this is response to the threads on 3rd party installers (http://dev.eclipse.org/mhonarc/lists/p2-dev/msg05226.html) and droplets)
Sorry for taking so long getting back to you. I have been away and did not feel like dealing with this issue as soon as I got back because this is likely to be long discussion :)
First let's start by comments on the wiki page (http://wiki.eclipse.org/Equinox/p2/Plan/3rd_party_installers)
- I think this page should be renamed to be "3 party installers on linux" as other systems generally have no issue invoking the p2 director.
- It would be good to give a description of the problem you are running into with the current solution. You are mentioning the pb about "uniqueness" of libraries, but iirc there are other problems. Having all the problems listed will make sure that the solution
we are creating will address them all, rather than discovering the problems piece meal and shoehorning a solution afterward.
- Why should feature.xml contain ranges? what do you define as "external dependencies"?
- I find the processing of droplets to be too complex. I think that a droplets needs to be a runnable repo plus something that identifies the feature(s) that must be installed. This way the work to be done by the droplet becomes easier. Wdyt?
More generally, when we met at EclipseCon France, we blue-skied the concept of droplets as a potential solution and it is great to see that you are making progress. However, given the other requirements that I gather from some of your comments on the wiki page,
I'm wondering if the droplet approach is the way to go. For example, we could also decide to go with an approach that generates a profile on the fly (or start from a stub profile) or structure the metadata differently to make it easier for you to patch, etc.
Finally, a minor point, in the mail , you are saying
"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 :-)."
and this is misleading. Indeed, since its inception p2 has always supported a model where Eclipse can be completely updated from one build to another. This is not just a feature on paper. This is automatically tested but more importantly this is actively being
used everyday by the development team which updates from one I-build to the next using p2, or by the EPP package maintainers when they verify that the SR0 package can be updated to SR1, and even to the next release. And, finally this is even works on Linux
when Eclipse is installed by the user (downloading the eclipse archive).
What you are describing is a situation specific to the way Eclipse is distributed on Linux by the package managers.
p2-dev mailing list