RFC: reducing wasted disk space from addon files

[Jacek Caban]

On 3/5/19 4:41 PM, Vincent Povirk wrote:
>> 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.


We used CAB files in very early Wine Gecko days, the move to MSI was a 
nice change. It moved installation logic to the right place. In case of 
Gecko it's not really a big deal: one directory and one registry key, so 
I don't feel strongly about it.


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


If we stayed with MSI instead of CAB (probably we'd need both .msi for 
downloader and .tar.* file for shared install) then, we'd have two Mono 
MSIs. Let's call them big and small. I have limited knowledge about MSI, 
but it should be possible to have small MSI be both part of the big 
package and its dependency. With that, current appwiz.cpl should work 
out of the box - small MSI would be installed as part of big MSI.


Then in mscoree, I imagine we'd need something among those lines:


if (!find_mono_installation()) {

     run_appwiz();

     if (!find_mono_installation()) // fail

}

if (small_msi_not_installed()) install_small_msi();

// consider Mono installed


You could do that whenever you attempt to load mono and in 
DllRegisterServer to take care of updates. How does that sound?


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


It works because of Wine's \\?\unix paths. It uses 
MsiInstallProduct("\\\\?\\unix\\usr\\share\\wine\\gecko\\wine_gecko-2.47-x86.msi") 
in my case. Trying To use such paths as GeckoPath value fails, but I 
didn't look at details. We could probably make it work with enough 
efforts. Or we could just run full appwiz.cpl install in such case.


Jacek