RFC: reducing wasted disk space from addon files

[Erich E. Hoover]

On Wed, Mar 6, 2019 at 9:35 AM Jacek Caban <jacek at codeweavers.com> wrote:
> ...
> 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.

I had some comments the last time I tried to submit these patches, so
I'll make some time to go over them and resubmit.  If I recall
correctly there wasn't anything particularly difficult, I just
unexpectedly got busy with other things.

On Wed, Mar 6, 2019 at 9:37 AM Vincent Povirk <vincent at codeweavers.com> wrote:
> ...
> That's an interesting idea. My understanding was that CAB files used
> by an MSI had to be flat (no directories), and this would prevent us
> from using the same CAB file as an MSI media and a stand-alone archive
> for the shared install.

Nope, but MSI has absolutely no capability for "recursively" unpacking
directories.  You must enumerate absolutely every single individual
file you want from the cabinet - no exceptions.  I have scripts that I
use to do this that take the complete contents of a structured cabinet
file and automatically create all the appropriate "Feature" and
"Component" entries for each file and directory in order to ensure
that the installer recreates the structure of the cabinet file.  I
personally find this to be incredibly useful for distributing
installers with a lot of structure in them.

> We could also put the c:\windows\mono directory in a separate feature
> so we don't have to install those files, but they'd still use space in
> the prefix from copying the MSI.

I'm not 100% sure I understand what you're trying to achieve, but I
assume that you're trying to avoid having duplicate information for
the same thing and to keep extraneous downloads to a minimum.  If you
wish then you can always have optional Features that don't get
installed, and if you place them in separate cabinet files (you can
always have more than one) then you can even skip downloading them if
you know that you won't need them.

> If you have a code example of an msi that installs another msi, that
> could be useful if we decide to use Jacek's idea, or if I need to make
> a fake .NET 4 msi.

I'm not sure how you generate your installers, but I create the "idt"
files that are used for populating the tables with msidb.  To call
another MSI I always use a CustomAction (see
CustomAc.idt/CustomAction.png) where the target should be a quiet
msiexec (yes, I know this looks crazy - but it is completely valid):
msiexec /i "[SourceDir]Bonjour.msi" /qn
You must also add the action to the InstallUISequence table (see
InstallU.idt/InstallUISequence.png) and the sequence _must_ match
ProgressDlg (or equivalent).

Best,
Erich
-------------- next part --------------
A non-text attachment was scrubbed...
Name: CustomAction.png
Type: image/png
Size: 9021 bytes
Desc: not available
URL: <http://www.winehq.org/pipermail/wine-devel/attachments/20190306/cddd62a5/attachment-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: InstallUISequence.png
Type: image/png
Size: 44686 bytes
Desc: not available
URL: <http://www.winehq.org/pipermail/wine-devel/attachments/20190306/cddd62a5/attachment-0003.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: InstallU.idt
Type: application/octet-stream
Size: 680 bytes
Desc: not available
URL: <http://www.winehq.org/pipermail/wine-devel/attachments/20190306/cddd62a5/attachment-0002.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: CustomAc.idt
Type: application/octet-stream
Size: 223 bytes
Desc: not available
URL: <http://www.winehq.org/pipermail/wine-devel/attachments/20190306/cddd62a5/attachment-0003.obj>