[RFC] Wine upgrade procedure (spec)

[Dimitrie O. Paun]

Hi folks,

It seems that we are getting ever so closer to 0.9. Slow, but steady.
Looking at the TODO, it looks like upgrading is one of the big 
showstoppers, in that it will affect (1) the end-user experience, and 
(2) how we deal with the configuration.

So this seems like a good time to start discussing this topic, as we 
need to eventually reach the elusive 0.9. This seems to be a difficult
topic, so we need to approach the problem well prepared. That is,
we need to first define (and agree) on what we need to solve here.
So after a tumultuous discussion on IRC, I decided to get the ball
rolling.

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

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).
   -- the upgrade should not erase registry settings that are
      managed by the user

Let's look at the use-cases:

 A. Global Install
    In this case, both Wine code, as well as applications are installed
    globally, for all users to access. This is the most Unix-like setup,
    but unfortunately the most difficult to support, due to the fact that
    Win32 apps simply expect a different environment. Since we can't 
    control application's code, this setup may present some limitations,
    but it may be sufficient for sites that need a limited set of 
    applications. For this to work, it is acceptable that we ship special
    scripts that know about the applications that are supported, so that
    they can work around inherent limitations in the applications 
    themselves. Users should transparently be able to use the new version 
    of wine, the next time they start wine.

  B. Mixed Install
     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.

Before we go any further, I'd like to ask everybody to contribute their
thoughts/requirements/desires so that we get a conprehensive view of
the problem we are trying to solve.

Thanks for reading this far!

-- 
Dimi.