On 09.10.2012 16:59, Pedro Giffuni wrote:
Hi Andre;
This initiative is hugely important. Thanks for working on it.
From: Andre Fischer
...
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.
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
By far the Windows case is most important.
I will add here some notes on how it's done on FreeBSD (and optionally linux).
Normal installation files:
For FreeBSD we don't use either .rpm or .deb format: we have epm generate
general archive files. These are later untarred and the ports system takes care
of re-tarring into our native pkg format (actually just a tar file with package
listing).
This sounds much like .deb packages (ar archive that contains two tar
archives), only that the suffix is still tgz.
As you can imagine generating packages takes a lot of time: it involves extracting and
repackaging.: it would be nice to have a "raw" mode that just installs things
and let our ports/packaging system take over.
I am not sure what you mean.
Updates:
FreeBSD will be transitioning RSN to the new pkgng format which takes care of
dependencies and updates in third party packages. I haven't looked at it in
detail but it is considered ready for prime time and has been tested
extensively. For the base system we have a system in place which uses bsdiff:
http://www.daemonology.net/bsdiff/
This would be very useful to release binary patches for security fixes or minor
updates. Google chrome used this same mechanism and later enhanced it into
Courgette:
http://dev.chromium.org/developers/design-documents/software-updates-courgette
I looked at that before I realized that msimsp.exe is already handling
the comparison of (binary) files and possibly the creation of binary
diffs (but probably not as good as either bsdiff or courgette.
-Andre
hth,
Pedro.
