[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
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