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: 1) installed in the prefix (current behavior) 2) installed in a per-user shared directory (Steam/PlayOnLinux/etc.) 3) 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().
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).
Best, Erich
*If you want to do this then I would recommend requiring the installer be in the directory (or next to it) and use the exact same installer code as the typical "#1" case (just with conditional install behavior on the files). You can safely strip the cabinet stream out of the installer to reduce the size if that's a big concern, but I would not use a separate MSI file with special code meant for handling this case (in my experience having separate installers eventually results in mistakes). If you would like to do this then I am happy to help with putting something together.