[RFC] Wine upgrade procedure (spec)

Vincent Béron vberon at mecano.gme.usherb.ca
Tue Jun 29 20:16:04 CDT 2004

Le mar 29/06/2004 à 09:29, Dimitrie O. Paun a écrit :
> On Tue, Jun 29, 2004 at 11:49:12AM +0100, Mike Hearn wrote:
> > Short of copying the entire codebase into the users account when they
> > explicitly choose to upgrade (ew, no other program does this) I can't see
> I agree, I personally hate this too, but Alexandre has a point in that
> this may be the most compatible setup, so at least in theory we should
> be able to support it just in case we need to employ it later. However,
> I'm fairly sure we don't need to actually get a working version for it
> at this time, we just need to make sure we could, if we wanted to, without
> replacing the entire upgrade mechanism.

Point2Play (Transgaming's Cedega frontend) does manage multiple Cedega
versions for the following reason: less risks of running into
regressions (you can specify which version to use for each application).

> > a good way of upgrading Wine while it's running that's free of race
> > conditions. For instance, you could be in the middle of upgrading when a
> > program you're running starts a new process: the wineserver may be using a
> > different protocol to what the DLLs expect.
> > 
> > I really don't think for now we should try and support upgrades while
> > running. It should probably be up to the packages/install scripts to alert
> > the user if they try that.
> Agreed. I think the most important thing is for Wine to integrate nicely
> with the system where it's running, so that rpm -U / yum update works as
> expected. If we go overboard with these sort of things, we may screw up
> the OS integration (remember, rpm -U must be able to run unattended for
> example), and this is a greater evil. Also, we have to be careful to not 
> be more catholics than the Pope: I really doubt that any significant number 
> of apps out there support 100% upgradability when they are running.

Numerous server packages do a shutdown as a preinstall step and a start
as a postinstall. It's quite ok for stateless programs, but could be a
bit rude for Wine users. Still, it's possible to fail the upgrade (via
rpm) if wine is detected as running at installation time. There's always
the chance of a race between the time the detection is made and actual
upgrade though.


More information about the wine-devel mailing list