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. 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. > > > 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. thx for taking this initative. rgds jan I. > > Regards, > Andre > > > [1] 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_**packages<http://wiki.openoffice.org/wiki/Building_installation_packages> > > ------------------------------**------------------------------**--------- > To unsubscribe, e-mail: > dev-unsubscribe@openoffice.**apache.org<dev-unsubscr...@openoffice.apache.org> > For additional commands, e-mail: dev-h...@openoffice.apache.org > >
