Community
Participate
Working Groups
Continuation from Bug 322477 comment 16. Refer to that bug for more context. -------- Scenario 2: A local bundle needs updating and requires a shared bundle that also needs updating. This scenario is more complicated and I have no solution for it at this time. I believe we would need changes in the way lock status is communicated to SAT4J or other changes in the planner. The current error returned by the planner is that bundle A v1.0.0 and bundle A v1.0.1 can not exist together. There is no mention that the "real" problem is that v1.0.0 can not be uninstalled because it is locked. The strategy used for Scenario 1 can not work since we do not have the dependency tree. The private bundle is not locked but a required bundle is. If people are happy with the behaviour described for the Scenario A patch I will release it today or Monday. If people have suggestions about solving Scenario 2 I'd love to talk to you.
Move all 3.8 bugs to Juno.
Continuing a discussion from bug 322477: Has it been considered to create a small application that directly goes into the update UI, a selection of "Check for updates" or "Install new software"? Given that elevated privileges seem to cost more effort than can be currently invested, I suggest: p2 might kindly ask the user to exit the full Eclipse and instead manually *run* an updater application *as Administrator*. That application would be minimal to avoid - vulnerability for untrusted plug-ins run with admin privileges - messing with "wrong" locations Shouldn't it be fairly easy to put together such an application? Later when s.o. finds the time the workflow could still be improved by launching the updater directly from Eclipse etc.
Is this issue still current?
I have no idea whether shared installs not writable to the current user are (still) a common practice. I personally don't see any need for this, but *if* lots of people are using Eclipse in this way (perhaps because their linux distro sets it up this way), then I assume this is one way of looking at a real problem: Eclipse may be crippled wrt updates for those users.
IMO, this goes against the goal of shared installs and should be closed as wontfix.
I imagine the normal workflow is that some admin maintains the shared installation and does so with admin privileges that give normal write access. E.g., an admin can do an update by running the shared installation or can install new software in the shared installation in the normal way.
