>
> What do you think?
> HTH,
> 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
> installs
>
> 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:)
>> HTH,
>> Ciao hh
>>
>> [1] = shared vs. local issue:
>>
https://bugs.eclipse.org/bugs/show_bug.cgi?id=319352
>>
>> -----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
>
>> bundles.
>>
>> 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@xxxxxxxxxxx
>>
https://dev.eclipse.org/mailman/listinfo/p2-dev
>
> _______________________________________________
> p2-dev mailing list
>
p2-dev@xxxxxxxxxxx
>
https://dev.eclipse.org/mailman/listinfo/p2-dev
> _______________________________________________
> p2-dev mailing list
>
p2-dev@xxxxxxxxxxx
>
https://dev.eclipse.org/mailman/listinfo/p2-dev
_______________________________________________
p2-dev mailing list
p2-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/p2-dev