RFC: reducing wasted disk space from addon files

[Hans Leidekker]

On Wed, 2019-03-27 at 18:30 +0100, Jacek Caban wrote:
> Let me put Wine Gecko into design consideration again, mostly because 
> it's simpler and I'd like to preserve that simplicity. Wine Gecko may be 
> considered a just another library in a distro. The fact that it's a PE 
> file is really just an implementation detail. From distro point of view, 
> it may be treated just like any other .so library: just install it into 
> the right place in a shared location. MSHTML would just find and try to 
> use it. If it can be found, no MSI is involved at all. Otherwise the old 
> way is used and installation is not shared. It's both simple and reliable.

Sure, if it's just files there's no reason to involve MSI.

> I know that Wine Mono is more complicated because it needs additional 
> setup, but it's not a reason to make the whole process too complicated. 
> I do not see how doing shared installation in appwiz.cpl helps with 
> anything. appwiz.cpl already caches downloaded MSI files and does the 
> installation in the most reliable way, which is a good for situations 
> where we need to recover from an invalid setup.

I don't see a reason to change the code in appwiz.cpl either.

> It still seems to me that doing the additional Wine Mono setup using a 
> separated small MSI file located in a shared location together with 
> other Mono files would be a cleaner solution than attempting shared 
> installation inside appwiz.cpl or refcounted shared MSI install.

If you want a separate package that is responsible for the same
registry data as the regular wine-mono package then you'll probably
want to block the install if you detect that the regular package is
installed (and the other way around).