Mailing-List: contact ooo-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: ooo-dev@incubator.apache.org
Received-SPF: pass (nike.apache.org: domain of awf.aoo@gmail.com designates
 209.85.214.47 as permitted sender)
Message-ID: <50743DF4.50005@googlemail.com>
Date: Tue, 09 Oct 2012 17:08:36 +0200
From: Andre Fischer <awf.aoo@gmail.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
 rv:15.0) Gecko/20120907 Thunderbird/15.0.1
MIME-Version: 1.0
To: ooo-dev@incubator.apache.org
Subject: Re: Installation patches
References: <50742228.5080002@googlemail.com>
 <CAP-ksogSFMt+e17bmwwvfshXgL7Y2_oUxDZ8WFickBi3DzGBAg@mail.gmail.com>
In-Reply-To: 
 <CAP-ksogSFMt+e17bmwwvfshXgL7Y2_oUxDZ8WFickBi3DzGBAg@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

On 09.10.2012 15:58, Rob Weir wrote:
> On Tue, Oct 9, 2012 at 9:10 AM, Andre Fischer <awf.aoo@gmail.com> wrote:
>> Hi,
>>
>> In the last days I looked into how to create installation patches for
>> updating AOO.  Using patches instead of full installation packages would
>> lead to smaller files to distribute for updating AOO on the next release.
>>
>> I have created a new Wiki page for my findings.  Please see [1] for an
>> overview and the details of how to create patch files.  Note that I have
>> concentrated on the Windows platform for the time being.
>>
> This is cool.  A few questions that I couldn't figure out from the wiki page:
>
> 1) How do you determine what files are changed?  Is this done from
> comparing two fukk installs?  From dependency analysis of the build?
> Manual analysis of the change logs and knowledge of dependencies?

This is done by the MsiMsp.exe tool from the Windows Installer SDK. It 
is fed with two msi files, the one that is to be updated (eg AOO 3.4)  
and the new target version (eg AOO 3.4.1).  The files lists contained in 
the msi files have the necessary information.  The comparison of the two 
file lists and diffing files that belong to both lists is the reason why 
MsiMsp.exe takes a couple of minutes to run.

>
> 2) Does it handle configuration/profile changes as well?  For example,
> between 3.4.0 and 3.4.1 we changed the default for the "check for
> updates" setting.

It can do that.  From what I read in the documentation, an msp file can 
basically change everything that is installed by an msi file.
But I don't know if the msp file that I created in my experiments did that.

>
> 3) You mention that the about box was not updated.  Is that just a
> simple bug?  Or a limitation of the approach?

The about box was partially updated.  I don't know why, yet.  Might by 
that the version number in the first line (the one that did not change) 
was read from the Windows registry and that I created an msp file as 
small update, which would not change the ProductVersion of the installed 
AOO.
So, probably a bug and not a limitation of the approach, but I am not sure.

>
> 4) How error-prone is this approach?  By this I mean how much testing
> would be required before we release an upgrade installer in addition
> to a full installer?

If we are lucky then we make a binary comparison between the files of an 
installed and a patched office and find no differences.  Then we have to 
compare the Windows registry keys associated with AOO. If we find no 
differences either then we need no further testing.

I would expect the binary equality of installed and patched AOOs but not 
100% equality of registry keys.

With differences only in registry keys we may be able to reduce 
additional testing to those parts of AOO that are influenced by the 
registry.

>   Are there any issues with binary compatibility
> with dynamic libraries, etc.?

I am not sure what you mean by that.  The MSP contains the files from 
the target version that either do not exist or are different in the 
original version.  After applying the patch the set of files in the AOO 
installation directory should be identical to a full install.

I found some hints that an MSP can be reduced in size by including 
binary diffs for files that exist in both the old and the target 
version.  But even then the patched office should be identical to the 
full install.


I know that there are still too many ifs and shoulds.  I am still 
piecing together information from different sources regarding the fine 
details of the Windows patch mechanism.

Any help is welcome.

-Andre

>
> -Rob
>
>
>> My results for the impatient:
>>
>> 1. I have written a Perl script with which I have created a Windows
>> Installer MSP patch file that updates an installed Apache OpenOffice 3.4 to
>> 3.4.1.  Its size is roughly a tenth of the full installation package.  There
>> are some minor problems, like the about box still displaying 3.4 as current
>> version in the first line.  The second line is OK.
>>
>> 2. There is already some support for the creation of patch files in the
>> make_installer.pl script but this functionality is inactive.  It is not
>> triggered by the makefile in module instsetoo_native/ and therefore I can
>> not say whether it would still work.
>>
>>
>> [1] http://wiki.openoffice.org/wiki/Building_installation_packages
>>
>>
>> Best regards,
>> Andre