openoffice-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andre Fischer <>
Subject Re: [proposal] Patches on Windows
Date Tue, 22 Oct 2013 11:31:05 GMT
On 22.10.2013 13:08, Rob Weir wrote:
> On Tue, Oct 22, 2013 at 6:20 AM, janI <> wrote:
>> On 22 October 2013 11:48, Andre Fischer <> 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 ?
> That would certainly have an even greater benefit when combined.
> If we don't refactor how we distribute languages we'd need many patch
> files, one for each language/platform combination.
>> 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/
>>> 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 and its
>>> modules, so that I can better debug the existing and the new code.
> At some point we'd need to think about how users find and get these
> patches.  The current mechanism notifies them about the update and
> sends them to or to an NL page.  The
> Javascript logic recommends what download to get.   We'd need to
> distinguish new downloads from patches.

The update notifications could link directly to patches when notifying a 
minor or micro release.  After all, they originate from an installed office.

Only users that go to our download page have to make a choice between 
full installation and patch.

> Also, perhaps complications if someone has installed AOO with lang A +
> lang pack B.  How is this patched?   There is a huge number of
> combinations there.  Jan's idea of a combined 200MB install with all
> languages sounds simpler, though larger.

Maybe I should point out that the creation of installation and patch 
sets on Windows is an amazingly complex task, even for the current 
single language install.  Then, as I have said already in an earlier 
mail, we have to distinguish between

- UI language of the installer
- UI language of OpenOffice
- supported languages for spell checking etc.

I don't know much about language support of installer and patches but I 
see a problem with spell checking.  Spell checking and grammar checking 
is done by extensions which have to be registered at first start.  That 
can not be done directly by the installer or a patch. They can at best 
trigger such a registration at first start.  And the whole area of first 
start and extension registration is a really dark area of our code.
I would like to first try to get the patch creation to work for single 
language installs and then we can think about how to handle multiple 


> Regards,
> -Rob
>>> 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]**wiki/Building_installation_**
>>> packages#Conditions_for_**creating_patches<>
>>> [2]**wiki/Building_installation_**packages<>
>>> ------------------------------**------------------------------**---------
>>> To unsubscribe, e-mail: dev-unsubscribe@openoffice.**<>
>>> For additional commands, e-mail:
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message