[Libreoffice-bugs] [Bug 122824] Main LibreOffice MSI Package should be compiled with external .cab file to reduce installation size requirements

[bugzilla-daemon at bugs.documentfoundation.org]

https://bugs.documentfoundation.org/show_bug.cgi?id=122824

Mike Kaganski <mikekaganski at hotmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|---                         |WONTFIX

--- Comment #4 from Mike Kaganski <mikekaganski at hotmail.com> ---
Hi!

Although I understand the rationale behind the proposal, unfortunately, this
request should not be implemented.

The three links mentioned in comment 0, that relate to technologies used for
chained installs, all relate to different technologies:

1.
https://docs.microsoft.com/en-us/windows/desktop/Msi/multiple-package-installations
This is about "Multiple-Package installations", a technology that is explicitly
marked incompatible with Windows Server with RDP (a scenario quite common among
users of LibreOffice). It requires to create an executable that will be
embedded inside the main MSI, which will provide a complex functionality
required for complex transactional processing. And while the mentioned problems
limit compatibility and increase maintenance cost, it's unclear how to make all
this packaged into a single download (the documentation only mentions packaging
the installer functions, which is different from packaging MSIs; and if MSIs
were packaged inside the primary MSI, then it's unclear how they would be split
from their CABs), unless a bootstrap used (see #3 below), which would increase
complexity and maintenance cost even more. Since this would require a bootstrap
anyway, I would dismiss this approach from the beginning. To mention one last
concert with this approach, I'm not sure that this will not *increase* the
total disk cost, because Windows Installer would need to cache both original
MSI, and embedded MSI.

2.
https://docs.microsoft.com/en-us/windows/desktop/Msi/concurrent-installations
This is marked "Deprecated"; "Do not use concurrent installations to install
products that are intended to be released to the public". And see the last
remark to #1 wrt size savings doubts.

3. http://wixtoolset.org/documentation/manual/v3/bundle/
WIX' Burn is an EXE which packs some other files (possibly including MSIs)
inside, like a self-extracting ZIP, with advanced installer-related
capabilities. This is absolutely like LibreOffice was packaged before 3.5.Using
this increases complexity for corporate deployments, since this would require
system administrators who want to deploy LO in AD domains using GPO to extract
the contents, and GPOs would be non-trivial, if working at all; and increases
maintenance cost. I'm not sure if this was the reason for our move at the time
of 3.5 (Andras is already in CC, so he can clarify or correct me if I'm wrong),
but IMO (as an ex-sysadmin with AD domains experience) that alone is a serious
problem to avoid reverting to .EXE-based installer.

I don't mention an option to provide simple ZIPs with split installers inside,
because that brings additional complexity to end users (non-corporate), and an
option for providing different packages for different scenarios (because that
would increase maintenance cost for TDF tremendously).

I close this WONTFIX because of the explained problems of the approach. Of
course, you are welcome to continue discussion here or in development mailing
list.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/libreoffice-bugs/attachments/20190121/47c58a7d/attachment.html>