Upgrade management

[Boaz Harrosh]

Mike Hearn wrote:

> There are a bunch of different ways we may want to upgrade the users 
> configuration:
>
> - Changes to $WINEPREFIX (~/.wine), for example:
>
>    - Introducing faked DLL headers
>    - Improved drive detection
>    - Changing the way the registry is stored
>    - Adding stuff to the virtual Windows drive
>
> - Modifying the registry
>
>    - Adding new keys
>    - Adding new appdefaults (default config options should be in the
>      code itself). While we have a policy of not having app-specific
>      hacks in Wine, some situations are very hard to resolve without
>      custom overrides. The Internet Explorer installer does a bunch of
>      things we really don't want it to do. The DCOM
>      installer needs custom overrides to convince it to install. And so
>      on.
>    - Registering new COM DLLs
>
>    (these all boil down to rerunning wine.inf)
>
> - Adding new binaries such as fonts, PE DLLs (think Moz AX control),
>   and so on. These may be placed somewhere in the Wine install directory
>   and then symlinked or copied (presumably linked) into drive C.
>
> This leads to the following questions:
>
> - How do we know when to upgrade the users wineprefix?
> - How do we avoid disturbing the users configuration?
> - What implementation do we use to upgrade it?
>
> One potential implementation for knowing when to upgrade the 
> wineprefix is to version it in a similar manner to how we version the 
> wineserver protocol: with a simple incrementing integer. This could be 
> stored in the registry, and Wines initialization sequence changed to be:
>
>      ...
>
>      Does $WINEPREFIX exist? No, call wineprefixcreate
>   -  Continue with startup
>   +  Yes? Check the wineprefix version key, if it is < the
>   +  version compiled into the source run
>   +  "wineprefixcreate --upgrade $oldversion $newversion", which then
>   +  performs the upgrade. If it exits with a zero exit code, the
>   +  version key is set to the number compiled into the source.
>   +  Then continue with startup
>
> If registry access is too difficult here, a simpler implementation 
> could be used: just store the number in a .version file.
>
> How do we avoid disturbing the users configuration? Alexandre already 
> laid out the plan for this, which is to have HKLM (HKEY_LOCAL_MACHINE) 
> devoted to the defaults we cunningly choose for maximum kewlness, and 
> HKCU (HKEY_CURRENT_USER) is where the users settings are stored. These 
> override the defaults, meaning we can change the default settings by 
> altering wine.inf, then bumping the wineprefix version so triggering a 
> remerge of the default registry contents.
>
> This means modifying each piece of code where we read the registry to 
> figure out a user-configurable option. The algorithm becomes:
>
> * Check the relevant key in HKCU, if it exists use it
> * Otherwise, if it's an appdefault, check the same key in HKLM
> * Otherwise, use the hardcoded default
>
> In most cases, there's no point in duplicating the points at which we 
> can control the defaults, doing it in the code is fine. So, it 
> basically means grepping the source to find out where we read settings 
> from, and changing them to use HKCU instead of HKLM, perhaps also 
> reading HKLM depending on the context of the setting (settings that 
> can be used in appdefaults should check both).
>
> I don't know how common these settings are but it might be worth 
> having a utility function either in a DLL or inline in a header to do 
> this. Registry code isn't complicated but it is tedious and easy to 
> mess up, so we might as well reduce code duplication at the same time.
>
> I think the best implementation is to keep the code responsible for 
> managing WINEPREFIX in wineprefixcreate, and simply extend this 
> program to handle upgrades as well. OK, so the name will be a bit 
> inaccurate but let's not change it - users are already discovering the 
> new program and getting used to it, no need to modify it now 
> especially as it's mostly an internal program.
>
> In the above example the old version and new version numbers were 
> passed to wineprefixcreate but most of the time that information 
> wouldn't be needed, for instance if we were to introduce fake DLL 
> headers we could simply check if they already existed and skip that 
> part if so. I think there's no harm in running wine.inf multiple 
> times, so we could just do that every time for both creation and upgrade.
>
> I *think* this addresses most of the issues with upgrades, though I'm 
> sure Alexandre can think of more :) Potential unresolved problems:
>
> - [How] do we lock wineprefix during upgrade so other processes
>   that are run hang about until it's done?
>
> - Currently moving registry keys about is done actually
>   in the code itself: we copy it across then print a message
>   telling the user to delete the old setting manually. There's
>   a fair bit of evidence that some users simply don't spot/understand
>   these warnings. Also, we want to allow people to upgrade Wine with
>   quite long intervals in between yet eventually this code gets deleted.
>
>   Maybe a better solution is just to have wineprefixcreate understand
>   how to move registry keys around in response to bumping the version.
>   If the script gets too unwieldy, we could split particular upgrades
>   into separate scripts in $prefix/share/wine.
>
> - Are there any wierd setups where parts of wineprefix are shared
>   between different users/systems that we need to take into account?
>
> Thoughts? Comments?
>
> thanks -mike
>
>
You did address most of the situations right. I have some scenarios that 
should be taken into account.
1. It is more than common to use more than one wine version on the same 
prefix. So what will the older version do. is it always future compatible?

2. Please do not silently touch a user's wineprefix. Users are used to 
have their wineprefix untouched. It is common practice to have a good 
solid production environment. And than try a new wine to see if a 
particular issue was fixed. The last thing they need is to later see 
that something was broken. Just have the check in place. and do a big 
FIXME. Than if the user uses a --upgrade command line switch. The actual 
upgrade is made. Or Just have the FIXME instruct the user to directly 
use wineprefixcreate for the upgrade. This way the user knows he/she 
needs to backup before running the new wine.

Free Life
Boaz