On Fri, 2019-03-15 at 15:17 -0600, Erich E. Hoover wrote:
How to handle an upgrade that needs both registry
changes and file updates?
Each supported mono/gecko version would need its own installer (and directory), just like now. When the distributor adds support for a new version of Wine then they would need to add the installer (and the unpacked files) to the appropriate shared location. Conceivably this is easier in the Steam/PlayOnLinux case if we give them a way to grab the URL for mono/gecko from a script, rather than having to figure it out themselves. If the cabinet file is structured with the file paths included then (after obtaining the URL) this becomes pretty easy for them, example:
- msidb -d wine-mono-4.8.0.msi -x image.cab
- mkdir wine-mono-4.8.0
- cabextract -d wine-mono-4.8.0 image.cab
That shouldn't be needed. All they'd need to do is run the installer with MONOBASEDIR set to the desired shared directory. The first install would create it, the second would increase the reference count. Removal of the package or an upgrade would decrement the reference count.
When can the files be removed?
The files can be removed when the version of Wine that uses them is no longer installed. In the case of a Linux distribution this is easy, since they only ever need one version at a time. In the case of something like Steam or PlayOnLinux then they would need the appropriate mono/gecko files for all the Wine versions that they support, and if they drop support for an older version then they should remove the corresponding files. In Steam's case they know which Wine version is being used by each game (not sure about PlayOnLinux or others), so they can clean up these files for any version that's not in use even if they have support for it.
It seems fragile to rely on external tools to track these files. A ref counted directory would automatically be removed when the last user is uninstalled or upgraded.