(this is response to the threads on 3rd party installers
(http://dev.eclipse.org/mhonarc/lists/p2-dev/msg05226.html) and droplets)
Hi,
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 [1], 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.
Pascal
[1] http://dev.eclipse.org/mhonarc/lists/p2-dev/msg05226.html
_______________________________________________
p2-dev mailing list
[email protected]
https://dev.eclipse.org/mailman/listinfo/p2-dev
