I'll refrain from technical comments since I'm not that good in p2 internals, but will comment on the problem description.
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
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
- I think this page should be renamed to be "3 party installers on
linux" as other systems generally have no issue invoking the p2
- 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
- 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
has to have the possibility to quickly build and deploy
Eclipse components to developers. It's just too expensive to
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