Re: [p2-dev] 3rd party installers, droplets, etc

[Krzysztof Daniel <kdaniel@xxxxxxxxxx>]

Hi,

Good to see you back, comments in line.

On Wed, 2013-07-31 at 11:50 +0200, Pascal Rapicault wrote:

> 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.

I thought that having the ability to crc-check your installation is not
something that only linux users want, that's why I wanted to keep the
work pretty much OS-agnostic (except security updates, which are linux
only). Limiting the work scope to linux only doesn't sound right to me,
but... on the other hand, it's just less work. Done [1].

> - 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.
Listed problems [2].

> - Why should feature.xml contain ranges? what do you define as
> "external dependencies"?
This is strictly connected to the security updates. In Eclipse package,
not all files are owned by Eclipse, f.e. jsch is only a symlink to the
file owned by jsch package. Now if jsch get a security fix, it is
rebuild, and changes it's version. This effectively breaks feature
resolution and p2.

The only thing that could work here IMHO (better sit down) is automatic
feature patch generation (find everyone who uses the jsch, and prepare a
feature patch, than find everyone who used patched feature and repeat).

> - 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?

Typical scenarios that imho require complex processing:
- two features submitting the same bundles. admin deletes (uninstalls)
one of them. Do we really want 
- feature submitting the same bundle as master
- features requiring each other

> 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.
It still does not solve security updates. It is impossible to install
features requiring features which have changed (unsatisfied
dependencies), unless P2 is capable of amending them.

> 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.

I did not meant to offend you or P2, but it's a misinterpretation or me
not being clear enough. I know that mentioned functionality does work,
and I guess I'd be opening a bug report if it didn't. 

I'm thinking of rather massive-scale deployments, where running p2
director on each workstation is not only a very difficult task - but
very error prone to users messing with the installation.

> Pascal
> 

Chris,

[1]
http://wiki.eclipse.org/Equinox/p2/Plan/3rd_party_installers_on_Linux
[2]
http://wiki.eclipse.org/Equinox/p2/Plan/3rd_party_installers_on_Linux#Current_problems

-- 
Krzysztof Daniel <kdaniel@xxxxxxxxxx>
Red Hat