[RFC] Wine upgrade procedure (spec)

[Mike Hearn]

On Tue, 29 Jun 2004 02:33:15 -0400, Dimitrie O. Paun wrote:
> Intuitively, upgrading wine is simple to understand: once a new version
> is installed, we need to get users in a state where they can use it.
> While simple to state, this problem is complicated by the various corner
> cases that can appear in Real Life (TM):
>   -- native vs. builtin DLLs handling
>   -- multiple Wine installations on a box
>   -- updating only some DLLs
>   -- integrating into the Unix environment
>   -- dealing with Windows software

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

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

>   B. Mixed Install

This is almost certainly the most common amongst our userbase today.

>      Here, Wine code is installed globally, but applications are
>      installed in the user's account. In a way is like (A) but with some
>      additional applications installed directly into the user's account.
>      Same requirements apply to this case as well.
> 
>   C. Local Install
>      Both Wine code, as well as applications are installed locally, into
>      the user's account. The Wine code is still installed globally by
>      the administrator (as in A & B), but it is copied locally before
>      it's being used. An upgrade in this case may require an explicit
>      action by the user, so the upgrade can happen at a controlled time,
>      when the user desires it.
> 
> 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.

thanks -mike