Bug 97991 - Reducing the size of the Windows Installer
Summary: Reducing the size of the Windows Installer
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Installation (show other bugs)
Version:
(earliest affected)
5.2.0.0.alpha0+
Hardware: All All
: medium enhancement
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: Installer-Windows
  Show dependency treegraph
 
Reported: 2016-02-19 01:34 UTC by Yousuf Philips (jay) (retired)
Modified: 2021-06-15 20:50 UTC (History)
8 users (show)

See Also:
Crash report or crash signature:
Regression By:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Yousuf Philips (jay) (retired) 2016-02-19 01:34:46 UTC
There has been some similar types of bug reports in the past (bug 44996, bug 49671) discussing how to reduce the file size of the installer and i believe this can be achieved through a number of approaches.

So analyzing the 5.1.1 installer on Windows which downloads at 211mb and fully extracts at 981mb here is the breakdown of the folders.

fonts        :  42.4 mb
help         :  38.0 kb
presets      :   1.0 mb
program      : 448.0 mb
readmes      :   2.1 mb
share        : 468.0 mb
system       :   1.6 mb
[root files] :  16.9 mb

I have written a batch script ( http://pastebin.com/FdHr0YLE ) that is linked from the "Installing in parallel on Windows" wiki page as a means of reducing the size of the paralleled installation. The script removes 496mb (51%) of its size by removing localized content that wouldnt be used by a user in these folders.

program/resource/   : 129 mb
share/registry/     :  70 mb
share/extensions/   : 275 mb

So in order to reduce the size of the installer and not have an installer per language, I'd like to suggest we create installers for a group of languages based on the language origin or geographical region and here are some examples.

LibreOffice-default (aka America, Africa, Australia): en (English), es (Spanish), fr (French), da (Danish), nl (Dutch), pt (Portuguese), pt-BR (Portuguese Brazil), en-ZA (English-South Africa), ar (Arabic)
 https://en.wikipedia.org/wiki/Languages_of_North_America
 https://en.wikipedia.org/wiki/Languages_of_South_America
 https://en.wikipedia.org/wiki/Languages_of_Africa
 https://en.wikipedia.org/wiki/Afrikaans_language

LibreOffice-westEU (aka West Europe): en, en-GB, de (German), pl (Polish), no (Norwegian), pt (Portuguese), fr (French), ro (Romanian), ...
 https://en.wikipedia.org/wiki/Germanic_languages
 https://en.wikipedia.org/wiki/Italic_languages

LibreOffice-eastEU (aka East Europe): en, hu (Hungarian), el (Greek), ru (Russian), uk (Ukrainian), ...
 https://en.wikipedia.org/wiki/Hellenic_languages
 https://en.wikipedia.org/wiki/Balto-Slavic_languages
 https://en.wikipedia.org/wiki/Uralic_languages
 https://en.wikipedia.org/wiki/Albanian_language
 https://en.wikipedia.org/wiki/Armenian_language
 https://en.wikipedia.org/wiki/Romanian_language

LibreOffice-cjk (aka South and Southeast Asia): en, zh-CN/zh-TW (Chinese), ja (Japanese), ko (Korean), id (Indonesian), vi (Vietnamese), th (Thai), ...
 https://en.wikipedia.org/wiki/East_Asia
 https://en.wikipedia.org/wiki/Southeast_Asia

LibreOffice-ctl (aka West, Central and South Asia): en, ar (Arabic), hi (Hindi), he (Hebrew), bn (Bengali), fa (Persian), ur (Urdu), tr (Turkish), ....
 https://en.wikipedia.org/wiki/Indo-Iranian_languages
 https://en.wikipedia.org/wiki/Turkic_languages

With the space saved within each of these 5 installers, we can then customize them to better cater to those languages/regions. For example we could include help within the installer rather than a separate download or with the CJK installer we could include addition open source cjk fonts like Noto Sans (bug 80346 comment 7).

We would still keep the full installer for users who want to get everything in one installer, but we would guide users to these separate installers by default when they go to the download page.

Alternatively we could have a font-free installer that would be used by users who are upgrading, either by downloading it from the website or through the update mechanism (bug 68274). Not sure how much of a reduction would come from doing this as the fonts are 42mb uncompressed, but i have no idea how much it would compressed.

For users who regularly upgrading once a month to the next point or fresh release, giving them a smaller download is an advantage, especially for those who are on slower connections.

I believe this concept could be used also on OS X, but dont think it would for Linux.
Comment 1 V Stuart Foote 2016-02-19 02:43:03 UTC
@Jay,

The problem would be in maintaining this diverse set of installers. MSI based installers are monolithic by design--we're lucky to have Andras Timar willing to maintain the Windows packaging for our VS build scripts.

Frankly, I don't have any issues with current packaging of Windows installers and offline help packs. The size of the installer is the price of admission--and, we distribute via ISO for DVD and in portable versions for those bandwidth constrained.

Suspect to get any traction on this, TDF would need to hire a FTE release engineer to specialize in Windows installer packaging--probably WiX based and move away from MS Visual Studio based packaging-- to be able to support the more granular packaging you are suggesting.
Comment 2 Óvári 2016-02-19 08:56:22 UTC
(In reply to Yousuf (Jay) Philips from comment #0)
A list of reasons for keeping the status quo is the optimal solution, i.e. the current arrangement where all the languages are in one file.

1. How would the new arrangement change the installation instruction (cf. http://www.libreoffice.org/get-help/install-howto/windows/) without complicating them further?

2. It could create confusion for LibreOffice users if there are different downloads for different locations.

3. In multicultural Australia there is a large likelihood that there is a person from almost every nation that LibreOffice supports is in Australia. Spelling checkers/grammar checkers/thesauri for English and another language is convenient by being bundled in the one installer.

4. It was interesting to note that you listed
ro (Romanian) in LibreOffice-westEU
hu (Hungarian) in LibreOffice-eastEU
when *hu* is more west and *ro* is more east.

5. There may be request to bundle LibreOffice on political alliances, eg. have a installer which has all the EU member states included.

6. The current set-up with separate downloads for each offline help in the language seems very simple on all account, except perhaps if there a download limits. Perhaps solutions could be found like:
a) bundling LibreOffice on the cover DVD of computing magazines
b) hosting LibreOffice on local ISP ftp servers
c) some other creative options which would not divert the resources of TDF from enhancing LibreOffice, Document Liberation

7. You mentioned that this concept would not work for Linux. Microsoft may be a temporary platform as:
a) Moving a city to Linux needs political backing, says Munich project leader
   http://www.pcworld.com/article/2082460/moving-a-city-to-linux-needs-political-backing-says-munich-project-leader.html
b) Russia Plans to Move to Linux
   http://news.softpedia.com/news/russia-plans-to-move-to-linux-500278.shtml
c) German town of Gummersbach migrates to Linux
   http://osssa.org.za/2014/10/07/german-town-of-gummersbach-migrates-to-linux/
d) There may be other migrations to Linux happening, whether in government or business, that are not in the news

The current arrangement WorksForMe.
Comment 3 Heiko Tietze 2016-02-19 09:15:06 UTC
A lot of good arguments from Óvári. To give another example: You placed en (en_GB or en_US?) in all packages, likely to offer English to everybody. But not taking the other big languages into account might be offending to many people. 
Messing up language with politics is always a big problem.

The better procedure would be to distribute only the hard-coded language and provide language packs (typically PO files) from another source (if possible directly from Pootle). Users could download the language pack from inside the program (Tools > Options > Language Settings).
Comment 4 Yousuf Philips (jay) (retired) 2016-02-19 20:47:35 UTC
(In reply to V Stuart Foote from comment #1)
> @Jay,

@Stuart,

> The problem would be in maintaining this diverse set of installers. MSI
> based installers are monolithic by design--we're lucky to have Andras Timar
> willing to maintain the Windows packaging for our VS build scripts.

@Andras: Would be good to hear your feedback.

> Frankly, I don't have any issues with current packaging of Windows
> installers and offline help packs.

I personally dont have any issues with the current installer as i have a 10MB fiber optics connection, i've spoken to people who had difficulties downloading it because of size (e.g. my brother who lives in Somalia where he has a shared 512kb connection and it took him ~4 hours to download it).

> The size of the installer is the price of
> admission--and, we distribute via ISO for DVD and in portable versions for
> those bandwidth constrained.

From what i could see, the ISO on DVD is available in north america and germany and most users will miss downloading the portable additions because its isnt on the standard download page for fresh and still and all links (e.g. the big 'Download Now' button on the homepage or in press releases and news articles ) link directly to < http://www.libreoffice.org/download/ >. It is interesting to see that the full portable version is only 166mb, which makes me wonder why the msi file is so much larger.

> Suspect to get any traction on this, TDF would need to hire a FTE release
> engineer to specialize in Windows installer packaging--probably WiX based
> and move away from MS Visual Studio based packaging-- to be able to support
> the more granular packaging you are suggesting.

Not sure if this would help, but there are msi editors like - http://www.instedit.com/ - so likely there maybe some commandline msi apps that could automate the process.
Comment 5 Yousuf Philips (jay) (retired) 2016-02-19 21:37:29 UTC
(In reply to Óvári from comment #2)
> 1. How would the new arrangement change the installation instruction (cf.
> http://www.libreoffice.org/get-help/install-howto/windows/) without
> complicating them further?

There would be no changes there, the changes would happen on the download page which would allow users to select which download they'd want, just like we currently have when a user selects to download help in their language. (e.g. http://www.libreoffice.org/download/libreoffice-fresh/?type=win-x86&version=5.1&lang=de )

> 2. It could create confusion for LibreOffice users if there are different
> downloads for different locations.

If this is presented in the right way, there wont be any confusion. Here is firefox's download page, and it isnt confusing ( https://www.mozilla.org/en-US/firefox/all/ ).

> 3. In multicultural Australia there is a large likelihood that there is a
> person from almost every nation that LibreOffice supports is in Australia.
> Spelling checkers/grammar checkers/thesauri for English and another language
> is convenient by being bundled in the one installer.

As stated, the full installer would still be available for to users who want all the languages, but no single user in Australia would need every language to be included in the installer, as there is a limit to the number of languages they speak/know.

> 4. It was interesting to note that you listed
> ro (Romanian) in LibreOffice-westEU
> hu (Hungarian) in LibreOffice-eastEU
> when *hu* is more west and *ro* is more east.

That was a typo, but you can see that i've listed < https://en.wikipedia.org/wiki/Romanian_language > under LibreOffice-eastEU.

> 5. There may be request to bundle LibreOffice on political alliances, eg.
> have a installer which has all the EU member states included.

Well they can grab the full installer. The main advantage of break up EU into west and east is because of the sizes of their dictionaries and the languages spoken their. Germany on the west has the largest dictionary at 70mb and the largest dictionaries on the east (hu, el, ro, ru) total to 27.5mb.

> 6. The current set-up with separate downloads for each offline help in the
> language seems very simple on all account, except perhaps if there a
> download limits. Perhaps solutions could be found like:
> a) bundling LibreOffice on the cover DVD of computing magazines
> b) hosting LibreOffice on local ISP ftp servers
> c) some other creative options which would not divert the resources of TDF
> from enhancing LibreOffice, Document Liberation

Strange that downloading separate offline help is acceptable, but we wouldnt consider the same for UI and dictionaries. Downloading multiple help files for multilingual individuals wouldnt be the simplest process. Many users wouldnt eve notice the 'LibreOffice in other languages' link on the download page, as i know i didnt notice it the first time i visited.

> 7. You mentioned that this concept would not work for Linux. Microsoft may
> be a temporary platform as:
> a) Moving a city to Linux needs political backing, says Munich project leader
>   
> http://www.pcworld.com/article/2082460/moving-a-city-to-linux-needs-
> political-backing-says-munich-project-leader.html
> b) Russia Plans to Move to Linux
>    http://news.softpedia.com/news/russia-plans-to-move-to-linux-500278.shtml
> c) German town of Gummersbach migrates to Linux
>   
> http://osssa.org.za/2014/10/07/german-town-of-gummersbach-migrates-to-linux/
> d) There may be other migrations to Linux happening, whether in government
> or business, that are not in the news

In the linux builds, we dont bundle all the language packs into the installer ( http://downloadarchive.documentfoundation.org/libreoffice/old/latest/deb/x86/ ), so users would need to download the separate language packs like they download the separate help packs on windows. Also most linux users get LibreOffice through their package manager, so they dont visit the website to download it, unlike Windows and Mac users.

Windows isnt going anywhere and that wont being changing anytime soon no matter which governments switch over to linux, as there are more people in businesses and in their homes than employees in a government.

(In reply to Heiko Tietze from comment #3)
> To give another example: You placed en
> (en_GB or en_US?) in all packages, likely to offer English to everybody. But
> not taking the other big languages into account might be offending to many
> people. 

Yes en meant en_US (our default english) so that it is available to everyone and the LibreOffice-default included all the major languages, that dont have their own dedicated installer.

> Messing up language with politics is always a big problem.

The organization was based on languages and geographics, not politics.

> The better procedure would be to distribute only the hard-coded language and
> provide language packs (typically PO files) from another source (if possible
> directly from Pootle). Users could download the language pack from inside
> the program (Tools > Options > Language Settings).

Yes it would be great to have the ability to add and remove languages and help directly from within LibreOffice, but of course that goes on the assumption that users have internet. ;D
Comment 6 Yousuf Philips (jay) (retired) 2016-02-20 14:31:39 UTC
Just as an additional piece of information about the breakup based on languages, the windows daily installer on @62 only includes a similar set of languages (en-US, de, ar, ja, ru, qtz).

http://dev-builds.libreoffice.org/daily/master/Win-x86@62-merge-TDF/current/
Comment 7 Óvári 2016-02-20 21:29:27 UTC
(In reply to Yousuf (Jay) Philips from comment #6)
> the windows daily installer on @62 only includes a similar set of
> languages (en-US, de, ar, ja, ru, qtz).

Not sure if “en-US, de, ar, ja, ru, qtz” are a similar set of languages; however for testing purposes they may give a broad cross-section of use cases.

If effort is going to be expended to create separate downloads, perhaps the best solution for minimal downloads would be to have:
* a core LibreOffice download (without any language pack); and
* each language as a *separate* download, not grouped at all.

There could be a page on LibreOffice.org to download language packs. It could look like:
http://www.libreoffice.org/download/libreoffice-fresh/?type=win-x86_64&lang=pick
with the title changed from “Please select your language” to “Language packs for Windows 64 bit”.

Having each language *separate* may make adding extra languages easier as:
* extra languages would not need to find which build of LO it should be added to;
* if there are similar languages that could be bundled together, but there is a political situation between the languages, this would be avoided;
* installation files would be the absolute minimum, satisfying bug 97991. Perhaps it would also reduce the amount of data through a government/enterprise installation (this could be a lot for installations in the magnitude of 10^4 or more).

The Mac build has challenges as the Release Notes state, “Mac OS X: Please start LibreOffice at least once before installing a LangaugePack.” (https://www.libreoffice.org/download/release-notes/). Perhaps this blocks this bug.

I thought that the current install is optimal, hence suggested WorksForMe; however, a core LO installation (without any languages) and separate language packs for each language would be the best solution for: reducing the download size, data travelling through a network when installations in the magnitude of 10^4.

Setting to status to UNCONFIRMED → NEW.
Comment 8 Andras Timar 2016-02-21 20:16:29 UTC
(In reply to Yousuf (Jay) Philips from comment #4)
> 
> @Andras: Would be good to hear your feedback.

Windows installer is created with help of a huge Perl script and standard tools from Windows SDK, such as msidb.exe.

Installer maker script is configurable in regards of languages you build in, and you can fine tune what go into the package in scp2. 

So, in theory, your goal can be reached.

I do not see why WiX or other installer maker frameworks would be better, but I see a big amount of work, if someone wants to migrate the scripts from one framework to the other. 

> 
> I personally dont have any issues with the current installer as i have a
> 10MB fiber optics connection, i've spoken to people who had difficulties
> downloading it because of size (e.g. my brother who lives in Somalia where
> he has a shared 512kb connection and it took him ~4 hours to download it).
> 

The situation was the same everywhere in the world 15 years ago. It is easy to get used to the comfort of high speed net connection, but I think 4 hours is not that much (maybe those users will not download LibreOffice daily for testing). If TDF ever decides to split the installer for different languages or geographies, I hope that the decision will be based on some survey and calculations of cost/benefit, not on anecdotal evidence.
Comment 9 Michael Meeks 2016-02-22 10:25:08 UTC
There are several goals here that are in tension with each other:

* reduce download size
     + I assume this is not a goal; since the help has significant size[1],
       and by bundling lots of help files in we will rapidly become larger
       than the existing download.
     + IMHO our ~static 200Mb download footprint is reasonably small.
	  + I suspect we could even increase this;
	    I'd say an upped 250Mb is reasonable myself.

* reduce update size ?
     + not an explicit goal thus far, but clearly after the initial download
       the size of the incremental updates is prolly by far more important
       than the download size itself. This is an area where TDF could invest
       in improving things for the vast majority of users.

* reduce install size
     + IMHO our ~1Gb install size is reasonably small too.
        + Office 2013 requires 3Gb:
	    + https://technet.microsoft.com/en-us/library/ee624351.aspx?f=255&MSPPError=-2147217396

* improve performance
     + there is some level of cost from having all languages installed,
       I don't think this has been characterized recently - but it might
       be interesting to do that again in eg. cachegrind to get a hard
       number of eg. startup cost with more langs installed.
          + this should have some technical fix of course.

* increased font bundling
     + seemingly we want to include more fonts for some locales
          + in general a bit of engineering work can usually save
            some space to free it up for more fonts without growing
            our download footprint, if we're indeed too worried
	    about that.

* distribute on-line help in the package
     + this essentially requires cutting the package into several
       pieces as suggested in order to keep the size sensible, that:
	   + increases our test burden
	     - 5x builds to test instead of one.
	   + somewhat increases our releng burden
	     - 5x builds to push -> more B/W
	         -> a relatively small effect though
  	   + download page simplification / complexity
	     - this will need re-engineering / tweaking
	     - will need to be different for Windows.
	     - how reliably can we detect people's locales
	       and map that to the "click here to download"
	       so 99.9% don't mis-download the wrong thing ?
	       If we have eg. 2% downloading the wrong thing
	       this adds ~4Mb to our apparent download size.
	   + some engineering to the packaging perl scripts
	     - some man days of work; no need to move to Wix.
     + I guess we would want to have roughly 20 languages
       in each of say five piece.
     + against this:
	  + would obsolete the on-line help for Windows users.
	  + what %age of users actually use the on-line help ?
	    Previous studies I've seen suggest a surprisingly
	    small number; and clearly an even smaller number
	    of them are off-line at the time.
	      ie. what is the benefit ? =)
	  + confusion wrt. "what is LibreOffice" - mine is
	    not the same as yours etc. "yours does not have my
	    language" etc.

* Anyway - all things are possible; I imagine if someone has
  done the engineering work already; and has a real proposal
  that might be more interesting.

	My general suggestion would be to optimize our size and
packaging instead; I imagine investing in reducing and compacting
and/or better arrangement in the MSI so that the compression works
better (it is IIRC per-file based not global so it can't see
commonality between eg pt_BR and pt if they are in different streams)
would be a better use of time. Other things like moving our clipart to
SVG from PNG might help too (it compresses better usually).

	And/or if we want to include more things, upping the target
file-size limit might be a good idea.

	Just my 2 cents.
Comment 10 Stephan Bergmann 2016-02-22 10:40:19 UTC
(In reply to Michael Meeks from comment #9)
> * improve performance
>      + there is some level of cost from having all languages installed,
>        I don't think this has been characterized recently - but it might
>        be interesting to do that again in eg. cachegrind to get a hard
>        number of eg. startup cost with more langs installed.
>           + this should have some technical fix of course.

And I assume that, although the .msi contains all languages, only a small subset is preselected during installation, so that a typical scenario will end up with only a small number of languages actually installed?
Comment 11 Yousuf Philips (jay) (retired) 2016-02-22 11:46:28 UTC
(In reply to Óvári from comment #7)
> Not sure if “en-US, de, ar, ja, ru, qtz” are a similar set of languages;
> however for testing purposes they may give a broad cross-section of use
> cases.

Yes these select languages were chosen as a means of testing a broad range of languages. e.g. ja to test asian/cjk languages, ar to test rtl/ctl languages

> If effort is going to be expended to create separate downloads, perhaps the
> best solution for minimal downloads would be to have:
> * a core LibreOffice download (without any language pack); and

There would always have to be atleast a single language pack in it or else it wouldnt work

> * each language as a *separate* download, not grouped at all.

Not sure how much benefit would be attained in this approach, as each language UI pack is normally quite small in size ( < 2Mb ).

(In reply to Andras Timar from comment #8)
> Windows installer is created with help of a huge Perl script and standard
> tools from Windows SDK, such as msidb.exe.
> 
> Installer maker script is configurable in regards of languages you build in,
> and you can fine tune what go into the package in scp2. 
> 
> So, in theory, your goal can be reached.

Glad to hear.

> The situation was the same everywhere in the world 15 years ago. It is easy
> to get used to the comfort of high speed net connection, but I think 4 hours
> is not that much (maybe those users will not download LibreOffice daily for
> testing).

Yes my brother doesnt use the daily builds, but with the cost/availability of electricity where he is, he chose not to download it.

> If TDF ever decides to split the installer for different languages
> or geographies, I hope that the decision will be based on some survey and
> calculations of cost/benefit, not on anecdotal evidence.

The main object of this issue was to save users from downloading an installer larger than what they need, which in turn would reduce TDF's bandwidth costs. It was also to make the installer closer in size to LO competitors like AOO (134Mb) and WPS (78Mb). But yes i do see the ramifications of this proposal as it would involve extra work for building as well as modification of the website, so it would be good for someone/committee to read through the proposal and make a decision in it.

(In reply to Michael Meeks from comment #9)
> There are several goals here that are in tension with each other:
> 
> * reduce download size
>      + I assume this is not a goal; since the help has significant size[1],
>        and by bundling lots of help files in we will rapidly become larger
>        than the existing download.
>      + IMHO our ~static 200Mb download footprint is reasonably small.
> 	  + I suspect we could even increase this;
> 	    I'd say an upped 250Mb is reasonable myself.

The proposal wasnt to include help packages as part of the installer, as that would highly increase the size, it was about removing things currently bundled and possibly include small useful extra items, like additional fonts, into particular installers. The old windows daily builds which only had english bundled were around ~120mb.

> * reduce install size
>      + IMHO our ~1Gb install size is reasonably small too.
>         + Office 2013 requires 3Gb:
> 	    +
> https://technet.microsoft.com/en-us/library/ee624351.aspx?f=255&MSPPError=-
> 2147217396

The install size of ~1Gb would be only if a user installed every single language in the installer, but most users are likely to only install 1 to 3 languages, which means the install size for most users would be around 600mb.

> * increased font bundling
>      + seemingly we want to include more fonts for some locales
>           + in general a bit of engineering work can usually save
>             some space to free it up for more fonts without growing
>             our download footprint, if we're indeed too worried
> 	    about that.

With the CJK font mentioned in the other bug being around ~100mb uncompressed, i would wonder how much it could be reduced in an .msi file.

> * distribute on-line help in the package
>      + this essentially requires cutting the package into several
>        pieces as suggested in order to keep the size sensible, that:
> 	   + increases our test burden
> 	     - 5x builds to test instead of one.

Is this about testing the installer or testing the languages, as if it is about testing the languages, CJK users would only be testing the CJK version, and of course download the extra help package to also test that.

> 	   + somewhat increases our releng burden
> 	     - 5x builds to push -> more B/W
> 	         -> a relatively small effect though

Yes there would be 5 more installers to push, but alot less B/W would be consumed from downloaders.

>   	   + download page simplification / complexity
> 	     - this will need re-engineering / tweaking
> 	     - will need to be different for Windows.

Ideally this would also work for Mac OS as well.

> 	     - how reliably can we detect people's locales
> 	       and map that to the "click here to download"
> 	       so 99.9% don't mis-download the wrong thing ?
> 	       If we have eg. 2% downloading the wrong thing
> 	       this adds ~4Mb to our apparent download size.

Ideally we'd show them the 6 versions and let them choose the one they want. We currently dont detect people's locales as a means of giving them the correct help pack.

> Other things like moving our clipart to
> SVG from PNG might help too (it compresses better usually).

I think > 25% of the clipart is SVG.

> 	Just my 2 cents.

Thanks for weighing in.
Comment 12 Mike Kaganski 2017-10-15 10:27:22 UTC
The recurring questions on AskLibO that keep asking why a help pack doesn't work suggest that having different installers for different languages bring more confusion than help.

The problem with help packs not working is that users use one UI language, but have help pack from another. They don't find it intuitive to match UI language and help pack language; the hypothetical one-helppacks-in-one-installer scenario would solve great number of user problems. Of course, at cost of increased download size.

The reduced size of program installer wouldn't be that small as to help people to go from 4 hrs of download to 15 minutes. More realistic is scenario when this will reduce to ~3 hrs; and that would still make most people who refuse to download now to keep refusing. But the cost will be great, both in terms of developers effort, infrastructure (size required for each version on servers), and user support in cases like where a single-regional setup is tried to be upgraded by all-lang installer (waste of bandwidth again, because user now needs to re-download required package?) or other interesting issues.

My strong opinion is WONTFIX.