RFC: reducing wasted disk space from addon files

[Erich E. Hoover]

On Tue, Mar 12, 2019 at 2:06 PM Vincent Povirk <vincent at codeweavers.com> wrote:
>
> On Tue, Mar 12, 2019 at 2:24 PM Hans Leidekker <hans at 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.