Hi, 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. Kind regards, Mikhail Kalkov ----- Ursprungligt meddelande ----- Från: "Pascal Rapicault" <[email protected]> Till: "P2 developer discussions" <[email protected]> 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) 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
_______________________________________________ p2-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/p2-dev
