Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [p2-dev] Follow up on shared install issue

I also thought that this could fix the issue we encounter for shared install, however I think it will just delay the problem to when the user installs something.
To be more precise, here is the situation I'm worried about
- When the EPP package is built, the bundles.info will contain the slf4j bundle
- When the user runs the install (and depending the repositories enabled), slf4j may end up being removed (because the code that computes the attachment of the current profile also uses the planner), thus producing a user bundles.info that is not a proper subset of the shared one. 
Even if this is not the real case, some users have shown more complex setup (install more, lock read only, etc.) that could end up revealing the issue and making the troubleshooting even more complex.

On 2010-08-21, at 10:51 PM, Ian Bull wrote:

Since the problem happens when we set roaming back to true (because we plan, but the plan isn't stable and thus things get removed), we could also fix it by forcing the roaming property in without computing a plan (just create a custom plan setting roaming back to true).  Again, this won't fix the root problem, but it will give the EPP guys a director app that will work.

cheers,
ian

On Sat, Aug 21, 2010 at 7:32 PM, Pascal Rapicault <pascal@xxxxxxxxxxxx> wrote:
Thanks to Ian's initial investigations, I have been able to find the root cause of the shared install issue but I don't have yet a solution.
The root cause seems to be a bug in the resolver (bug 323322). I may have found a workaround by solving (323319) but it does not fix the root cause just hides the problem. At this rate, I will likely need Daniel's help to solve this, but he is still away on vacation for some time, so at this point the only ETA I can give is sometimes during the first week of September.
In the meantime, if we wanted to have the EPP package bundles.info to be correctly generated, we could build a custom version of the planner with workaround 323319 that the EPP team could use to build the packages.

PaScaL

_______________________________________________
p2-dev mailing list
p2-dev@xxxxxxxxxxx
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
p2-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/p2-dev


Back to the top