RFC: reducing wasted disk space from addon files

[Hans Leidekker]

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 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().

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.