|Re: [p2-dev] Shared installs and our EPP Packages|
> Looks like some improvements in 3.6 destabilized the shared installI disagree with this statement. 3.6 contains changes that stabilized things over 3.5.
> scenario, so I guess we should start by looking at the weaknesses of the
> current version and see how we can get it into the stable form it had in
> 3.5 again..
At this point, based on Ian's experiments I believe that the problems we are seeing are caused by the EPP packages being incorrectly provisioned (something, someone messes around with files on disk). In the same situation, p2 3.5 would have failed in the same way.
> What do you think?
> Ciao, hh
> -----Original Message-----
> From: p2-dev-bounces@xxxxxxxxxxx [mailto:p2-dev-bounces@xxxxxxxxxxx] On
> Behalf Of Pascal Rapicault
> Sent: Friday, August 13, 2010 11:06 AM
> To: P2 developer discussions
> Subject: Re: [p2-dev] Shared installs and our EPP Packages
> When we first implemented this, we thought of various strategies (I
> don't remember them all). The one we picked was the one that allowed the
> least check on startup ensuring that shared installs would not be slower
> than normal ones, and also made sure that the eclipse being run was
> truly p2 enabled.
> I'm all for revisiting this but to start with what are the particular
> scenarios that we are trying to improve?
> As for the particular issue being mentioned in (1), I think this problem
> was likely resulting from several issues that got addressed in 3.6:
> 1) the behaviour of the resolver to always pick the highest
> version of a bundle
> 2) the absence of locking all the IUs when resolving for shared
> On 2010-08-13, at 9:56 AM, Haigermoser, Helmut wrote:
>> Please not that the strategy of having two bundles.info files and
>> trying to detect a broken, shared .info file seems to be buggy, some
>> time ago one of my collegues ran into an issue with the
>> "org.eclipse.equinox.concurrent" plug-in(1) that will render the
>> shared .info file "broken" and refuse to use whatever you changed in
>> the shared configuration.
>> We could fix this bug and keep the strategy, or should we think about
>> a different strategy, maybe not having two files and synching them but
>> having one master and one (user) .info file with just the differences,
>> be it additions or removals?
>> Let me know what you think:)
>> Ciao hh
>>  = shared vs. local issue:
>> -----Original Message-----
>> From: p2-dev-bounces@xxxxxxxxxxx [mailto:p2-dev-bounces@xxxxxxxxxxx]
>> On Behalf Of Francis Upton
>> Sent: Thursday, August 12, 2010 7:23 PM
>> To: P2 developer discussions
>> Subject: Re: [p2-dev] Shared installs and our EPP Packages
>> The logic says: If the shared bundles.info contains all the
>> bundles in the local one, then use the local one. That is, if the
>> shared bundles.info is a subset, then it's ok to use the local
>> bundles.info -- because the local just contains additional bundles.
>> However, if somehow the local one removes bundles (or updates them),
>> then we will likely hit problems down the road, so revert and use the
>> shared bundles.info file
>> -- this is the inconsistency I was talking about. Since we hit this
>> inconsistency, we assume the local bundles.info file is 'wrong' and we
>> use the shared one -- which of course doesn't have the newly installed
>> I think at this point a detailed error should be logged in the startup
>> though because that condition is something the is not supposed to
>> happen and that would help people diagnose these sorts of problems in
>> the future. Right now it just does not work and we don't know why. In
>> general my feeling is that p2 should complain a little more if things
>> are not right and give a lot of diagnostic information which will help
>> track down issues like this in the field.
>> Does that make sense?
>> Yes, thanks for your clear and thoughtful explanation.
>> p2-dev mailing list
> p2-dev mailing list
> p2-dev mailing list
p2-dev mailing list
Back to the top