On 22 October 2013 13:48, Andre Fischer <awf....@gmail.com> wrote: > On 22.10.2013 13:32, janI wrote: > >> On 22 October 2013 13:10, Andre Fischer <awf....@gmail.com> wrote: >> >> On 22.10.2013 12:20, janI wrote: >>> >>> On 22 October 2013 11:48, Andre Fischer <awf....@gmail.com> wrote: >>>> >>>> Hello everybody, >>>> >>>>> At the moment we provide full installation sets for every release and >>>>> for >>>>> all platforms and languages. An installation set has a typical size of >>>>> roughly 150MB. The size of the actual changes is typically much >>>>> smaller. >>>>> Using patches instead of full installation sets would considerably >>>>> reduce >>>>> the amount of data that has to be downloaded by users. For new users >>>>> without existing installation of OpenOffice we probably still need the >>>>> full >>>>> installation sets. >>>>> >>>>> Would this also be an opertunity, to look at how we release >>>>> languages ? >>>>> >>>> I have tested making an installation set that contain all released >>>> languages, it has a rough size of 200Mb, which is a lot friendlier than >>>> <# >>>> langauges> * 150Mb, and gives international users (like me) the option >>>> to >>>> switch UI. >>>> >>>> Friendlier to our servers, but not to our users. But this problem is >>> orthogonal to creating patches. And we have to distinguish what language >>> support we are talking about: >>> - UI language of the installer >>> >>> We still need the installer in every language, and that the bit that I >> have >> not done. I envised a fork in the installer so it loads the OS language of >> the host. >> > > There are two parts to this: setup.exe and the included msi. Adding > support to the msi might be easier than we think. At least the 'File' > table has a 'Language' column. I think the table that contains the UI > messages that are displayed during the installation has something similar. > If this column acts as a filter then all we have to do is add entries for > all languages and let the msi select the right ones automatically. The > setup.exe is build by the NSIS installer creator. I don't know if and how > it supports multiple languages. > > > >> - UI language of OpenOffice >>> >>> that is what I have done with --with-lang >> >> - Languages supported by spell checker et al. >>> >> that is simple files added to the distribution, and the main reason for >> the >> extra 50Mb. >> > > Yes, but how do we decide which of the many spell checkers to install? > All of them all the time? Or only a subset, depending on the locale?
You are right, we might just want to install the UI part with the local spell checker, then the user can choose to add spell checkers as needed. > > > >> Why do you see this as a disadvantage to our users. >> > > I only see the larger download as disadvantage. I don't know how many > people really would want to have even more spell checkers installed on > their system and would accept an increase of 1/3 of our already large > installation sets. > The main reason for using patches instead of full installation sets is > their reduced size. Including all available languages might reduce that > advantage. > You misunderstand me. I am 100% for patches !! with all available languages in the install set, we will only need 1 patch, so in total its an advantage. But as said earlier, I agree with "small steps" first make the patches work, then consider the rest. rgds jan I. > > -Andre > > >> Many users have multiple languages for spell checkers etc installed, and >> some (especially people working internationally) also have multiple UI >> languages. >> >> rgds >> jan I. >> >> >>> >>> All I miss is to pursuade the installer to choose the right default UI >>>> language. >>>> >>>> >>>> >>>> Note that such patches can only be made for minor or micro releases. >>>> >>>>> Major releases would still be full installation sets. >>>>> >>>>> I have worked in the past months on finding out how our build system >>>>> has >>>>> to be modified in order to create patch sets on Windows. This has >>>>> resulted >>>>> in a set of conditions [1] that have to be fulfilled by the >>>>> installation >>>>> sets. One example of a condition that we currently don't fulfill is >>>>> that >>>>> files must not be deleted in minor or micro releases. >>>>> >>>>> Up to now I have taken two full installation sets and then tweaked the >>>>> newer one until I was able to >>>>> a) successfully create an .msp patch file and >>>>> b) successfully apply it to an OpenOffice that was installed by the >>>>> older >>>>> install set. >>>>> >>>>> I would now like to change the build system, especially the solenv/bin/ >>>>> make_installer.pl script and its modules, so that the installation >>>>> sets >>>>> it creates can be used without further changes to create patch sets. I >>>>> would also like to add the patch creation itself. >>>>> >>>>> +1, I have added a single comment on the wiki page about zero length >>>>> >>>> files. >>>> >>>> please consider making the patch mechanism in its own module. >>>> >>>> >>>> For this I propose and seek lazy consensus for the following changes: >>>> >>>>> 1. When a new release is made, create data files that are added to our >>>>> version control system (semi automatically) that allow us on the next >>>>> release to check and/or enforce the conditions. >>>>> >>>>> 2. Before the next release is made, read the data files of the previous >>>>> release and check and/or enforce the conditions. >>>>> >>>>> 3. When a new minor or micro release is made, first create the full >>>>> installation sets, then create patches. >>>>> Besides the data files mentioned above, this also requires access >>>>> to >>>>> the installation sets of the previous release. >>>>> >>>>> 4. Cleanup of the logging mechanism used by make_installer.pl and its >>>>> modules, so that I can better debug the existing and the new code. >>>>> >>>>> >>>>> Most of the proposed changes have a low impact on the current creation >>>>> of >>>>> installation sets. They basically only add new features (collecting >>>>> information about a release, adding it to the VCS, reading the >>>>> information >>>>> on next release, checking conditions, creating patches). However, some >>>>> conditions can be enforced automatically (like using the same uuids for >>>>> components in one release and the next) and that can introduce >>>>> regressions, >>>>> ie break installation sets. But I think the danger of that is not >>>>> bigger >>>>> than with many other new features or bug fixes. I don't expect >>>>> conflicts >>>>> with build system changes made or proposed by Jan. >>>>> >>>>> Go for it, if you do in trunk, I can merge it into my branches. >>>>> >>>> I also very little conflict with my build system work, like maybe 1-2 >>>> changed makefiles. But thats no serious conflicts, and more me being >>>> aware >>>> of the changes. >>>> >>>> Thanks. When I eventually check in the changes I will report the >>> details. >>> >>> >>> >>> >>>> More details about the creation of installation sets and patches can be >>>>> found in the Wiki [2]. >>>>> >>>>> I really like the idea, that brings us one step closer to a more >>>>> >>>> installation. >>>> >>>> Thanks. After I looked at the make_installer.pl script I toyed with >>> the >>> idea of reimplementing it completely. But that would require too much >>> time. So I will cope with 40 characters long identifiers like '$** >>> scpactionsinproductlanguageres****olvedarrayref'. But maybe I will >>> clean >>> >>> up things like sort algorithms that make bubblesort look fast (see >>> sorting_array_of_hashes() in solenv/bin/modules/installer/**s**orter.pm< >>> http://sorter.pm>)**. >>> >>> That are 20 lines of bad code that can be replaced by a single short >>> line >>> of Perl code that is much more expressive. >>> >>> -Andre >>> >>> >>> thx for taking this initative. >>>> >>>> rgds >>>> jan I. >>>> >>>> >>>> Regards, >>>> >>>>> Andre >>>>> >>>>> >>>>> [1] >>>>> http://wiki.openoffice.org/******wiki/Building_installation_**<http://wiki.openoffice.org/****wiki/Building_installation_**> >>>>> **<http://wiki.openoffice.org/****wiki/Building_installation_**<http://wiki.openoffice.org/**wiki/Building_installation_**> >>>>> > >>>>> packages#Conditions_for_******creating_patches<http://wiki.**** >>>>> openoffice.org/wiki/Building_****installation_packages#**<http://openoffice.org/wiki/Building_**installation_packages#**> >>>>> Conditions_for_creating_****patches<http://wiki.** >>>>> openoffice.org/wiki/Building_**installation_packages#** >>>>> Conditions_for_creating_**patches<http://wiki.openoffice.org/wiki/Building_installation_packages#Conditions_for_creating_patches> >>>>> > >>>>> [2] >>>>> http://wiki.openoffice.org/******wiki/Building_installation_******<http://wiki.openoffice.org/****wiki/Building_installation_****> >>>>> packages<http://wiki.**openoffice.org/**wiki/** >>>>> Building_installation_****packages<http://wiki.openoffice.org/**wiki/Building_installation_**packages> >>>>> > >>>>> <http://wiki.**openoffice.org/**wiki/Building_**installation_** >>>>> packages <http://openoffice.org/wiki/Building_**installation_packages> >>>>> <http://wiki.**openoffice.org/wiki/Building_**installation_packages<http://wiki.openoffice.org/wiki/Building_installation_packages> >>>>> > >>>>> ------------------------------******--------------------------**--** >>>>> --**--------- >>>>> To unsubscribe, e-mail: dev-unsubscribe@openoffice.****a**pache.org< >>>>> http://apache.org**> >>>>> <dev-unsubscribe@**openoffice.**apache.org<http://openoffice.apache.org> >>>>> <dev-unsubscribe@**openoffice.apache.org<dev-unsubscr...@openoffice.apache.org> >>>>> > >>>>> >>>>> For additional commands, e-mail: dev-h...@openoffice.apache.org >>>>> >>>>> >>>>> >>>>> ------------------------------****----------------------------** >>> --**--------- >>> To unsubscribe, e-mail: >>> dev-unsubscribe@openoffice.**a**pache.org<http://apache.org> >>> <dev-unsubscribe@**openoffice.apache.org<dev-unsubscr...@openoffice.apache.org> >>> > >>> For additional commands, e-mail: dev-h...@openoffice.apache.org >>> >>> >>> > > ------------------------------**------------------------------**--------- > To unsubscribe, e-mail: > dev-unsubscribe@openoffice.**apache.org<dev-unsubscr...@openoffice.apache.org> > For additional commands, e-mail: dev-h...@openoffice.apache.org > >
