+1, 3.6 is much more stable than 3.5 with respect to shared installs. However, we also have more people using shared installs now (because of UAC on Windows Vista / 7 ).
cheers, ian On Fri, Aug 13, 2010 at 3:05 AM, Pascal Rapicault <[email protected]>wrote: > > 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.. > I disagree with this statement. 3.6 contains changes that > stabilized things over 3.5. > 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? > > HTH, > > Ciao, hh > > > > -----Original Message----- > > From: [email protected] [mailto:[email protected]] 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: [email protected] [mailto:[email protected]] > >> 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 > >> [email protected] > >> https://dev.eclipse.org/mailman/listinfo/p2-dev > > > > _______________________________________________ > > p2-dev mailing list > > [email protected] > > https://dev.eclipse.org/mailman/listinfo/p2-dev > > _______________________________________________ > > p2-dev mailing list > > [email protected] > > https://dev.eclipse.org/mailman/listinfo/p2-dev > > _______________________________________________ > p2-dev mailing list > [email protected] > https://dev.eclipse.org/mailman/listinfo/p2-dev > -- R. Ian Bull | EclipseSource Victoria | +1 250 477 7484 http://eclipsesource.com | http://twitter.com/eclipsesource
_______________________________________________ p2-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/p2-dev
