RFC: reducing wasted disk space from addon files

[Vincent Povirk]

> FWIW, the reason why Gecko wouldn't need an additional package is that
> those parts are in Wine itself. We have Wine-specific iexplore.exe
> -regserver (and -unregserver) that are used as an equivalent of
> uninstalling Mono MSI package. It's easy to do for registries; files may
> more tricky, but fake DLLs should be doable this way. Gecko way may be
> not suitable for Mono, but may be worth consideration. Do existing files
> prevent native .net installer from running or installing them? Are the
> files that you intend to install just fake DLLs? Could we have Wine
> install them itself?

Part of the purpose of the files and registry keys is to prevent the
native .NET installer from running. Most .NET application installers
will try to run the .NET installer, and once it runs we can't reverse
it.

We install some files which require Mono to build. I expect there will
be more in the future.

The files and registry keys could probably be installed by .inf, given
that we have access to the files themselves which have to come from
Wine Mono. My concern is that we wouldn't have a reliable way for
programs like winetricks to remove them before installing native .NET.

I'm going to be making another attempt at preventing the .NET 4.0
installer from trying to install over Wine Mono, and one possible
outcome is that we have to install a stub MSI to impersonate .NET 4.0.

> An important thing in past decisions was that prefixes should be
> transferable. For example, if you copy a prefix that uses a shared Mono
> to another machine that does not have Mono globally installed, it should
> still work. I guess now that have a reliable downloader/installer, we
> may just install required package the old way on the other machine. This
> can be done, but may need a special attention. Esp. if you'd implement
> the idea of "small" Mono MSI file, you'd need to make sure that it would
> not prevent complete install when shared location can not be located in
> runtime.

I'm starting to favor the CAB approach for this reason. For us to
consider Wine Mono to be installed, we need the MSI and the Mono
runtime. We could have logic which checks for both of these, and
reruns the MSI if something is missing. That would take care of
switching from a small MSI to the full one, but it makes checking for
an install more complex. If we always have the Mono runtime installed
in a shared addon location, we only need to check there. We can then
run the MSI from the addon location unconditionally, and the MSI
component will only do the install when it needs to.

This leaves the question of which component runs the MSI, and when. If
mscoree does it, then appwiz.cpl only needs to manage static files,
but doing the install via appwiz.cpl won't create a working
installation. One would have to register mscoree or do a prefix
update. If appwiz.cpl does it, that's some extra complexity that I'm
not sure it should have.

> Another thing to consider is that shared Gecko/Mono installation may be
> not mappable to DOS drives (eg. removed z: drive). We could probably
> fallback to full "old way" in such case. Or maybe we could make it work
> with \??\unix paths, I'm not sure.

How does this work currently? I would expect that an MSI can't install
from outside the prefix in this configuration.