RFC: reducing wasted disk space from addon files

[Erich E. Hoover]

On Fri, Mar 15, 2019 at 11:31 AM Hans Leidekker <hans at codeweavers.com> wrote:
>...
> 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.

To be clear, I'm not thinking symlinks are the best plan either - but
it could be a quick and dirty stepping stone.  I think that what you
really want to do is call the installer with the absolute path to the
files whenever install_mono/install_gecko is called, that way if it's
called with a different Wine version then it will load the correct
files without having to toy with the files in the prefix.

> 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:
1) msidb -d wine-mono-4.8.0.msi -x image.cab
2) mkdir wine-mono-4.8.0
3) cabextract -d wine-mono-4.8.0 image.cab

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

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

Yeah, I'm not sure that it's a good idea to have shared gecko/mono
files without them being managed by a distribution or some form of
automated prefix management.  Maybe there's a way to do this that I'm
not seeing, but I think there's a good chance that you end up with
orphaned files no matter what.

Best,
Erich