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