RFC: reducing wasted disk space from addon files

[Vincent Povirk]

It would be counter-intuitive for uninstalling a package from one
prefix to affect all other prefixes. I suppose registering features
and components probably wouldn't do any harm, but they don't help us
either. If we need to uninstall a shared package, we need to be able
to do the uninstall in any prefix, not just the one that installed it.

Ideally, we shouldn't need the original msi (which contains the cab
file and therefore an extra copy of most of the files) to remove the
shared files. If there's a way to save just the installation database
and use that, we could do that, but that depends on whether the
uninstall process depends on the features and components having
already been registered within the same prefix.

I really don't think prefix reference-counting is viable for reasons
I've already explained.

Anyway, here's a possible design:

User-local addon installs will be extracted to:
~/.local/share/wine/addons/hash-of-wine-path/addon-arch/version

We will assume that each install of Wine will require only one version
of each addon for each architecture. We can also assume that if the
Wine version changes (which changes the addon version requirement),
the prefix will have to be updated. So if we find a version of an
addon that we don't need, we can safely delete it. To handle z:
deletion, on prefix update we could make a symlink from a fixed
location in c: to the specific addon path for the current Wine
install.

When we need to download an addon from the Wine website, appwiz will
download the msi file to a temporary location. It will create a
temporary folder in the addon-arch directory and install the msi with
SHAREDINSTALLDIR set to that location. The msi will just install the
files and not register itself when that property is set. If the
install succeeds, appwiz will rename that directory to the version
number (which may fail if another prefix did the same thing, that's
ok). Then the msi can be deleted so we're not duplicating the
contents, along with any obsolete versions.

For most users, there will be only one wine install. If there are
multiple installs, we may duplicate some files. I think that's OK.
Developers are likely to have a separate "source tree" and "installed"
version of Wine. We can help with that case by making the build system
able to download and install the pre-built addons if configured to do
so.

Then once we've done all that, we notice that we're using msi only as
an archive format and abandon it in favor of cab or something.