RFC: reducing wasted disk space from addon files

[Jacek Caban]

On 3/6/19 4:08 PM, Erich E. Hoover wrote:
> On Wed, Mar 6, 2019 at 6:05 AM Jacek Caban <jacek at codeweavers.com> wrote:
>> On 3/5/19 4:41 PM, Vincent Povirk wrote:
>>> ...
>>> 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.
> MSI files contain a CAB file within them, so if all you need is the
> ability to distribute a single unified file then we can just
> distribute an MSI file and extract the CAB.  I have patches in staging
> for implementing msidb (the tool needed to do this),


It's not strictly related to this topic, but I like the idea of msidb 
having. Using msidb instead of winemsibuilder in Gecko build scripts 
would be a welcomed change. It would make VS builds, that Austin uses 
for Valgrind, able to do proper MSI build too.


> so you could
> conceivably build a process around:
> 1) download MSI
> 2) extract CAB with msidb
> 3) unpack CAB with cabextract to the desired destination folder
> This may not be the best approach though, depending on what you want
> to achieve (read on).


Sure, but I'd rather let MSI do that for us, like it's currently done.


>> ...
>> 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.
> Yes, it is possible to have one MSI installer call another installer.
> It is also possible to have an MSI installer dependent upon
> environment variables (so the environment variable tells it not to
> unpack the files, so it just installs the registry keys).  It is also
> possible to create MSI installers that use _separate_ CAB files (not
> included in the MSI file itself), so you can download the MSI
> instructions but not download the "files".  If you combine this with
> environment-variable control then you can conceivably save download
> bandwidth and use a single MSI for both "shared" and "prefix-specific"
> behavior.  This technique also has the benefit of giving you the CAB
> file you want without having to extract it from the MSI file.


appwiz.cpl downloader is aware of prefixes can cache downloaded so that 
they won't be downloaded by future prefixes. MSI can't do that, so it's 
better to leave downloads to appwiz.cpl.


> I, regrettably, have a lot of experience creating strange installers
> like this.  If you are interested in this approach then I can put
> together a simple example to demo how this approach can work.


Note that it's distro (or Proton) that would be responsible for 
installing it in a shared location. Distros building Gecko themselves 
should probably use something like make install. For those using our 
binaries, a simple compressed .tar file is probably more convenient.


Jacek