On 09.10.2012 15:58, Rob Weir wrote:
On Tue, Oct 9, 2012 at 9:10 AM, Andre Fischer <awf....@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
