Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 343768

Summary:	[shared] Support for elevated privileges for updates in shared install
Product:	[Eclipse Project] Equinox	Reporter:	DJ Houghton <dj.houghton>
Component:	p2	Assignee:	P2 Inbox <equinox.p2-inbox>
Status:	RESOLVED WONTFIX	QA Contact:
Severity:	enhancement
Priority:	P3	CC:	Ed.Merks, overholt, pascal, peter, stephan.herrmann, tjwatson
Version:	3.7
Target Milestone:	---
Hardware:	PC
OS:	Mac OS X - Carbon (unsup.)
Whiteboard:

Description DJ Houghton

2011-04-25 15:19:02 EDT

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.

Comment 1 Thomas Watson

2011-06-08 11:31:03 EDT

Move all 3.8 bugs to Juno.

Comment 2 Stephan Herrmann

2012-08-18 12:28:59 EDT

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.

Comment 3 Ed Merks

2020-02-23 05:25:06 EST

Is this issue still current?

Comment 4 Stephan Herrmann

2020-02-23 06:30:35 EST

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.

Comment 5 Pascal Rapicault

2020-02-23 19:58:09 EST

IMO, this goes against the goal of shared installs and should be closed as wontfix.

Comment 6 Ed Merks

2020-02-24 00:17:54 EST

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.