[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
RE: [p2-dev] Shared installs and our EPP Packages
|
Ciao Pascal :)
I totally agree, let's first define the use cases we want to support
before jumping to any changes of strategy! :)
To me it seems like we need to think of the "shared install" use case as
a very common use case in the future, on some Windows machines it will
even be the eclipse default case so it's going to be heavily used.
Looks like some improvements in 3.6 destabilized the shared install
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..
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
