[RFC] Wine upgrade procedure (spec)

[Dimitrie O. Paun]

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.

> 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. In other 
words, an app that has more than one config/data file, would need to do 
locking to make sure that the data set that's spread around the files is 
treated atomically during upgrade. I personally think we can live with the
race when we read in the registry files, but if that causes problems, we
can add some locking so that we can read them in atomically. Maybe Alexandre
can comment on this, he seems to have thought of this scenario already.

> > We can also look at some important use-cases that we need to support,
> > but before we do, the following must hold true in all cases:
> >    -- administrators should be able to install a new Wine on the
> >       system easily with "rpm -U" (or equivalent).
> 
> This is a use case we should definitely support but perhaps only in a
> special configuration where wine is a script which checks for a new
> version and copies it across next time it's started, or something like
> that.

That will not work, we install as root, we run it as a regular user.
Really, I see no difference between this and option (B) from the upgrade
mechanism point of view, I think the challange here is to simply get
the apps to run in this environment. We may need scripts that create
fake directories with a bunch of symlinks, etc. but this is another matter.

> > In all of the above, there is always state in the user directory. Thus,
> > it is imperative that the upgrade process makes sure that after the
> > upgrade, the user-private state is consistent with the new code base.
> > Also, any solution must take into account that the registry must be
> > created on the fly, as it is created when registering the DLLs.
> 
> One possible solution here is a new wineserver request that switches the
> registry files in use, so to update the registry in a way that doesn't
> disturb currently running programs you can connect to a new wineserver
> instance (separate socket), switch registry files to "system.reg.new" or
> whatever, run wine.inf and then have another request which does an atomic
> rename of the registry files over the new ones once merged. This means the
> old wineserver instance is still using the old registry file inodes, but
> next time the Wine session is started up it'll be using the new registry.

Right, I was thinking along the same lines, but I'm not sure we can work with
the same wineserver. For one, we will have one wineserver instance per user,
running as the user, whereas for global install we need one that runs as root.
But we do need to create these files at runtime, so we may need a special
operation mode to achive it.

-- 
Dimi.