[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [p2-dev] The future of Eclipse upgrades

John, maybe you're right and the way users interact with Windows has changed.  All I can do is draw on my experiences here.  In the past (windows XP) many Windows applications could manage their own upgrade cycle (Office, Java, Firefox, Thunderbird, Picasa, Flash, etc...). Using p2, RCP applications could also manage their own upgrade cycle.  On *nix environments, it was often the administrators responsibility to upgrade these applications.

Now, with these more 'locked down' Operating Systems, p2's self upgrade story has changed.  If other applications require the user to 'launch as admin' to upgrade, then this is probably sufficient for us too.  However, if other applications are able to manage their own upgrades (on launch, for example), then we might have some work to do if we want to support this too.

Backing up a bit, I've been thinking about this in light of the Java Sun / Oracle VM issue[1] .  I've been thinking about what we would have to do to support the discovery of important Eclipse fixes.  Obviously gaining the appropriate access rights is something we would need to support.  One way this could be done is to run the upgrade agent as a separate process (that can *somehow* become authenticated). 

[1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=319514

So I'll re-focus this thread a bit.  Do we (the p2 team) think that self upgrades on Operating Systems that enforce User Access Control is an important (and interesting) problem to focus on during Indigo?

cheers,
ian



On Fri, Jul 30, 2010 at 2:45 PM, John Arthorne <arthorne.eclipse@xxxxxxxxx> wrote:
Maybe there is a difference between Windows 7 and Vista here. On Vista, I have to become Administrator to install Eclipse into Program Files. Therefore it is consistent that I have to become Administrator again to perform updates. In fact I'm not sure we can do much better without Eclipse being registered with the OS as a trusted installer. As a regular user, and can install/update additional plugins and they are stored in a location writeable by me. This is all quite consistent with shared install on other platforms I believe.

We can likely improve the experience here though. Perhaps we can make automatic updates not offer to upgrade bundles that are located in directories not writeable by the current process (actually Windows does pretend to allow writing certain kinds of files under Program Files but in fact stores them elsewhere, but we have a technique for detecting this case already).

John


On Thu, Jul 29, 2010 at 1:13 PM, Ian Bull <irbull@xxxxxxxxxxxxxxxxx> wrote:
I had the pleasure of running Eclipse on Windows 7 and the Eclipse upgrade story concerns me a bit. On Windows 7 (and maybe Vista, I'm not sure), I was able to unzip an Eclipse install the Program Files directory and launch.  While this directory was writable by the unzip utility, it's not writable by Eclipse, and we are put into a shared install mode.

For the most part this works fine, however, we won't be able to upgrade (using p2) when SR1 comes out.  Eclipse has been designed so that you can install new plugins in a shared install, but you cannot upgrade the base (without becoming a super user).  Technically this is no different from *nix environments, however, I would argue that there is a perceived difference.  

1. You never had to become a Super User before (Window XP)
2. And more importantly, you could 'install' Eclipse without becoming a super user, so why do I need to become an SU to upgrade?

I'm not even sure how to become a super user on Windows.

There are a number of bugs related to Eclipse and Windows 7, but most of these appear to be related to installing new plugins.  The bugs don't concern me (too much), but the more general decision not to allow upgrades to the base seems like it will have serious consequences.  This obviously isn't just an Eclipse problem, but an RCP problem too.

What do others think? I'm not a regular Windows user, so maybe this isn't really a problem.  Would windows users expect to launch Eclipse in SU mode to upgrade it?  Is there a way to put a p2 agent in SU mode (or at least bring up one of those helpful warnings when we upgrade "The Eclipse process is trying to write to the Program Files directory. Are you really really really sure you want to allow this?").

Is this something that we should be thinking about for our Indigo plan?  

cheers,
ian

--
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



_______________________________________________
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