[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [p2-dev] Clarification of greedy-ness (especially with respect to feature patches)

Wow David, that was a great summary.

I spent my evening re-reading bug 247099 (certainly a great read) and I agree with your summary.

One (unrelated) thing I noticed was your statement about pack.gz files. We should be clear that these files must be kept around (unless you can be certain that you have no nested jars or both the producers and consumers are using the same JRE). To recap, if you build with JRE 1.6 and try to install with JRE 1.7, this will fail if you have nested jars (and pack.gz files). This is because of a change in the binary format of the jar processor.  p2 will handle this case by falling back to the unpacked (canonical) forms.

cheers,
Ian


On Thu, Nov 29, 2012 at 6:35 AM, Pascal Rapicault <pascal.rapicault@xxxxxxxxxxxx> wrote:

I’m Pascal Rapicault and I approve this message J

 

From: p2-dev-bounces@xxxxxxxxxxx [mailto:p2-dev-bounces@xxxxxxxxxxx] On Behalf Of David M Williams
Sent: November-28-12 11:31 PM
To: P2 developer discussions
Subject: [p2-dev] Clarification of greedy-ness (especially with respect to feature patches)

 

p2 committers,

For this year's Simultaneous Release document, I wanted to add a sentence or two on why it was important ... in the context of our Simultaneous Release ... to specify (or publish) greedy="false" for runtime-optional dependencies.  

In the past, we just said "do it" and for the reasoning pointed to bug 247099 [1] and the wiki page [2] both of which are pretty complicated. One thing I'd like to confirm with you experts is that ... as far as I know ... it is not possible for an adopter to provide a customer with a "feature patch" for something that was installed via greedy=true. Right so far? So some adopters would have to jump through hoops (that I don't even know) to maintain some installed products if their customers happened to install some particular thing from some particular repository -- if it caused a critical bug in their product. Sound right? I've not provided a reason why someone would want to have greedy=true and am not sure I know one ... for the common repo. I do see the rationale mentioned in the bug for "services" where an OSGi server with a tightly controlled repository might want to roll-out changes that way ... but ... if any of you have a (brief) reason or example of when to use greediness in the Simultaneous Release, I'd appreciate hearing that too.

My full write-up is at

http://wiki.eclipse.org/SimRel/Simultaneous_Release_Requirements#Provide_optimized_p2_repository_.28partially_tested.29

But I've pasted the relevant section below [3] for your ease of reviewing.

And ... please note! ... I do not want to re-start the long debate in bug 247099 ... I just want to make sure the brief reasons I have stated are accurate and adequate.

Thank you for any review/confirmation you can provide (and apologies in advance if I've asked before and its already been explained to me and documented elsewhere),


[1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=247099
[2] http://wiki.eclipse.org/Equinox/p2/Publisher
[3]
= = = = = =
... the repositories produced and contributed must use p2 publishers that produce greedy='false' in the content metadata for runtime-optional dependencies. See bug 247099 and the p2 Publisher wiki for some history and details on this issue of greedy vs. non-greedy requirements. But in brief, to have a runtime-optional dependency be non-greedy is important for several reasons, especially in an IDE environment. First it gives ultimate control over what is installed to the user, based on their feature selection, instead of depending on what happens to be available from the repositories they are pointing to at that moment it time. It also makes it much easier for adopters to be able to predict (and maintain) what their users have installed. In fact, if something is runtime-optional, but pulled into an install because someone did not specify greedy='false' meta-data, there is no way an adopter can provide a patch feature to one of their customers if that optional bundle causes a bug.
= = = = = =


_______________________________________________
p2-dev mailing list
p2-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/p2-dev




--
R. Ian Bull | EclipseSource Victoria | +1 250 477 7484
http://eclipsesource.com | http://twitter.com/eclipsesource