On Fri, 2019-03-15 at 10:11 -0600, Erich E. Hoover wrote:
On Tue, Mar 12, 2019 at 2:06 PM Vincent Povirk vincent@codeweavers.com wrote:
On Tue, Mar 12, 2019 at 2:24 PM Hans Leidekker hans@codeweavers.com wrote:
Did you consider using the existing msi for the shared scenario? You'd run the installer like this in each prefix (without mono installed):
$ wine msiexec /i wine-mono-4.8.0.msi MONOBASEDIR=z:/home/user/shared_mono/wine-mono-4.8.0
The package would need an extra registry entry that saves MONOBASEDIR, which would then be read by mscoree.get_mono_path().
I've considered and dismissed other solutions where msi is used to manage shared files, it seems very unsafe.
It sounds like you're trying to cover three possible use cases:
- installed in the prefix (current behavior)
- installed in a per-user shared directory (Steam/PlayOnLinux/etc.)
- installed globally by a package from the user's distribution
If you are going to still default to #1, then maybe place the burden of #2 and #3 on the "distribution" - have the installer just manage registry keys and don't touch the shared files at all. Make the distribution manage placing the shared files in the appropriate directory, either by unpacking the tarball or by extracting the contents of the MSI file, and then in appwiz.cpl:install_addon we just need to detect this directory and call the installer* to setup the appropriate registry entries (MONOBASEDIR=...). Conceivably this could also setup a symlink to the shared directory, which would avoid having to complicate the behavior of get_mono_path().
Symlinks don't work well if you want to be able to move the prefix to a different machine. I don't think splitting the responsibility for the files and registry data between Wine and a management or distribution tool is a good idea. How to handle an upgrade that needs both registry changes and file updates? When can the files be removed?
If you are trying to make #2 the new default behavior then I think we run a risk of having lots of "orphaned" mono/gecko/etc. files as prefixes are updated over time. We can try to refcount how many Wine installs are using the folder, but a lot of those installs are going to get deleted with "rm -rf ~/.wine" without uninstalling mono/gecko from the prefix or, worse, duplicated without incrementing the refcount. This situation isn't completely terrible, but I can see how we could end up chewing up a bunch of disk space over time and that we'd have to give people directions on how to clean it up. So, I would personally lean towards making #2 a conscious choice (by the user) or managed automatically by an external tool (Steam/PlayOnLinux/etc. case).
Your options #2 has cleanup issues too. If rm -rf ~/.wine leaving behind a stale shared directory is a concern then you could put the shared directory inside the first prefix.
If you find that the shared directory no longer exists you can simply run the locally cached package to do a repair install.