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
- UI language of OpenOffice
- Languages supported by spell checker et al.
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
'$scpactionsinproductlanguageresolvedarrayref'. 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/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_**
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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org
