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