Difference between revisions of "Building installation packages"

From Apache OpenOffice Wiki
Jump to: navigation, search
m (Extended the section about the Windows installer a bit)
m (Probably found root cause for one of the known issues.)
 
(19 intermediate revisions by 3 users not shown)
Line 1: Line 1:
 
==Installation packages==
 
==Installation packages==
−
The building of installation packages is the last step in building Apache OpenOffice.  It takes place in the main/instsetoo_native module.  It basically consists of collecting all files that are to be installed and putting them into an archive that can be installed on the targeted operating system.  The installation technique depends on the operating system:
+
The building of installation packages is the last step in building OpenOffice.  It is triggered by the <code>makefile.mk</code> in <code>main/instsetoo_native/util/</code> but most of the work is done by the <code>solenv/bin/make_installer.pl</code> and modules under <code>solenv/bin/modules/installer/</code>.  It basically consists of collecting all files that are to be installed and putting them into an archive that can be installed on the targeted operating system.  The files and other items like registry entries (only on Windows) are defined as script items in the <code>scp2</code> module.  The installation technique depends on the operating system:
 
;Windows:An [http://en.wikipedia.org/wiki/.msi MSI] that is run by <code>setup.exe</code>.  The use of <code>setup.exe</code> allows the installation of some Windows redistributables. It is built as <code>loader2.exe</code> in <code>main/desktop/win32/source/setup/</code>.  It runs an upgrade instead of a full installation if
 
;Windows:An [http://en.wikipedia.org/wiki/.msi MSI] that is run by <code>setup.exe</code>.  The use of <code>setup.exe</code> allows the installation of some Windows redistributables. It is built as <code>loader2.exe</code> in <code>main/desktop/win32/source/setup/</code>.  It runs an upgrade instead of a full installation if
 
:*an upgrade key read from <code>setup.ini</code> exists in the Windows registry
 
:*an upgrade key read from <code>setup.ini</code> exists in the Windows registry
Line 9: Line 9:
 
;MacOSX:A [http://en.wikipedia.org/wiki/Apple_Disk_Image DMG] archive that is (can be?) copied into the <code>/Application</code> directory.
 
;MacOSX:A [http://en.wikipedia.org/wiki/Apple_Disk_Image DMG] archive that is (can be?) copied into the <code>/Application</code> directory.
  
−
Installation packages are created by Perl script <code>main/solenv/bin/make_installer.pl</code> and a larger number of Perl modules in <code>main/solenv/bin/modules/installer/</code>.  The <code>make_installer.pl</code> script is run by the makefile <code>main/instsetoo_native/util/makefile.mk</code>.
+
===How To Create Installation Sets===
 +
Installation sets are created when you run <code>build</code> in <code>instsetoo_native</code>.  How to set up the build system is described in the [[Documentation/Building_Guide_AOO|building guide]] and [[Documentation/Building_Guide_AOO/Step_by_step|step by step building guide]].  When your build system is configured you can build OpenOffice like this:
 +
    cd main/instsetoo_native
 +
    source ../winenv.set.sh # or another *.[sS]et.sh, the name depends on your platform
 +
    build --all
 +
You can speed up the building process by running it in multiple parallel processes like this
 +
    build --all -P4 -- -P4
 +
where the numbers depend on how much your CPU can handle and if you still want to work with your computer while you are building.  On a 4 core CPU the <code>-P4 -- -P4</code> option leaves a Linux system responsive while a Windows system starts to lag.
  
−
==Patch sets==
+
The <code>build</code> command in <code>instsetoo_native/<code> (with or without the <code>--all</code> option) builds installation sets for all languages that where given to <code>configure</code> via the <code>--with-lang</code> option.  Without the <code>--with-lang</code> option the set of languages defaults to <code>en-US</code>.  There is a second multiplication factor for the installation sets that are built: the package format.  The set of package formats depends on the platform.  For Windows that is <code>msi</code>, for Linux that is <code>deb</code> and/or <code>rpm</code> and for Mac that is <code>dmg</code>.  There is another package format that is available on all platforms.  The <code>archive</code> is built by default, but only for <code>en-US</code>, even when more languages where specified via <code>--with-lang</code>.
  
−
A patch differs from a full installation package in that it only contains the modified files. For the update from AOO 3.4 to 3.4.1 this leads to size reduction of roughly 90%.
+
If you want to build only one installation set for a fixed combination of language and package format then
 +
    cd instsetoo_native/util
 +
    dmake <target>_<language>.<package>
 +
The list of available targets is listed when you run
 +
    dmake help
 +
The list of available languages is the one you gave to <code>--with-lang</code> and the list of available package formats is the one explained above (<code>archive</code>, <code>msi</code>, <code>deb</code>, <code>rpm</code>, <code>dmg</code>).
  
−
The structure, content and creation of patch sets depends on the operating system.
+
==Patches on Windows==
 +
A patch differs from a full installation package in that it only contains the modified files.  For the update from AOO 3.4 to 3.4.1 this leads to size reduction of roughly 90%.
  
−
===Windows===
 
 
On Windows there are Windows Installer patches (or .msp files) similar to installation packages (or .msi files).  These are self-contained packages that, for example on double-click from the file explorer, perform the update automatically and without the need for further applications.
 
On Windows there are Windows Installer patches (or .msp files) similar to installation packages (or .msi files).  These are self-contained packages that, for example on double-click from the file explorer, perform the update automatically and without the need for further applications.
  
−
Msi and msp files are COM Structured Storages (http://en.wikipedia.org/wiki/COM_Structured_Storage) and (at least in the case of AOO) contain at least two streams. One contains the files to install or update, and the other holds a relational database whose tables contain information about the installation (for msi files) or update process (for msp files).
+
Windows MSP updates can have three different types (see http://msdn.microsoft.com/en-us/library/windows/desktop/aa370579%28v=vs.85%29.aspx for more details):
 +
*Small Updates
 +
*Minor Upgrades
 +
*Major Upgrades
  
−
The msi and msp databases can be read or modified in three different ways, each of which depends on the Windows Installer SDK (current version for Windows 7 is 5.0) which is contained in the MS Windows SDK:
+
As small updates do not allow a change of the version number, a minor upgrade is the one the one best suited for Apache OpenOffice updates.
 +
A major upgrade should be used for ?.0 releases.  While a major upgrade corresponds with our use of .msi files, the creation of minor upgrades requires additional work.  On the conceptual level the creation of a minor upgrade is quite simple.
 +
# Locate two installation sets, old and new or source and target, both as a pairs of .msi and .cab file.  The .msi file is a database with a set of tables that describe the files and registry entries to install.  The .cab file contains the actual files.
 +
# Create a .pcp file that is basically a data file that drives the patch creation.
 +
# Run the MsiMsp.exe command from the Windows installer SDK. This results in a single .msp file.
 +
# The .msp can be applied on a computer which has the source installation set installed.  The result of that is equivalent to installing the target installation set.
  
−
# Through a set of executables that can read and modify msi and msp files.  Msidb.exe (http://msdn.microsoft.com/en-us/library/windows/desktop/aa370083%28v=vs.85%29.aspx) gives read and write access to the database stream.  Msimsp.exe creates the msp patch file.
+
===Conditions for creating patches===
−
# By using the Windows Script Host together with the WiRunSQL.vbs script to access the database stream via SQL commands.
+
There are a number of conditions that both source and target installation sets have to fulfill.  Breaking this conditions may result in very subtle errors either during the patch creation or application. The conditions are defined on values in tables in the .msi files of source and target installation sets:
−
# A custom program that uses the Patchwiz.dll to get access to the database stream.
+
* In the <code>Property</code> table:
 +
** The values of the <code>UpgradeCode</code> property differ.<br> Identical values indicate the same version => no need to create a patch.
 +
** The values of the <code>ProductCode</code> property are identical.
 +
** The values of the <code>PRODUCTBUILDID</code> property differ and the newer value is higher than the old value.
 +
* Adding and deleting files, registry entries, components, features:
 +
** New files can be added but only to new components in new features.
 +
* Files and Components (and registry entries?) must not be deleted.<br>If a file is not needed anymore than it may be possible to set its size to zero instead of deleting it completely.<br>
 +
'''jani:''' would rename be possible ? zero length files are often a problem with backup/copy.<br>
 +
'''andre:'''No, the name has to remain unchanged.  But maybe we can put one byte into files.
 +
* For components that exist in the <code>Component</code> table of the old installation set:
 +
** There is a corresponding component in the new installation set (ie. components must not be deleted).
 +
** Its <code>ComponentId</code> values do not change.
 +
** Its <code>Component</code> values do not change.
 +
** That means that the component names (ie the <code>ComponentId</code> values) do not contain the full AOO version number. Just the major version number would be OK.
 +
** Maybe: The <code>KeyPath</code> values point to the same files.
 +
* For registry entries that exist in the <code>Registry</code> table in the old installation set:
 +
** There is a corresponding registry entry in the new installation set (ie. registry entries must not be deleted).
 +
** The <code>Registry</code> values do not change.
 +
** The <code>Key</code> values do not change.
 +
** That means that the component names (both the <code>Registry</code> and <code>Key</code> values) must not contain the full AOO version number.  Just the major version number would be OK.
 +
* In the <code>File</code> table:
 +
** The <code>Sequence</code> values remain identical for files that are in both the old and the new installation sets, regardless of whether a file has changes or not.
 +
** The <code>Sequence</code> values are unique.
 +
** Probably: The <code>Sequence</code> values form a sequence without holes.
  
−
Tables can not be deleted from the database stream with method 1 but with method 2.  Never tried method 3.
+
===Current state===
 +
The patch creation on Windows has been reimplemented.  The existing implementation was inactive, incomplete and undocumented and therefore could not be reused.
  
−
Windows MSP updates can have three different types (see http://msdn.microsoft.com/en-us/library/windows/desktop/aa370579%28v=vs.85%29.aspx for more details):
+
===Workflow===
  
−
;Small Updates:Changes to the msi file and application files. No change of either ProductCode nor ProductVersion
+
In the typical use case patches are created from the previous version to the currently released version.
−
;Minor Upgrades:No Change to ProductCode.<br/>Change of the ProductVersion
+
−
;Major Upgrades:Change the installation into a different product.<br/>Change of the ProduceCode.
+
  
−
So, a minor upgrade is the one best suited for Apache OpenOffice updates, because we don't change the product but only the version number.
+
The process of creating MSP patches can be broken down into three steps:
  
−
Creating a msp patch is basically quite simple:
+
*Build installation sets of OpenOffice with the additional option <code>release=t</code>.
−
# Take two msi files, the old version that is to be patched, and the new target version.  Lets call them msi_o and msi_t.
+
:This enforces the conditions that where described above by integrating information about the source release into the build process.  This information is taken from downloadable installation sets. These are expected in the <code>ext_sources/</code> directory.  When they are missing (which is the default) then they are downloaded from <code>archive.apache.org</code>.  This should not lead to band width problems because release builds usually are made only by the release manager twice a year.
−
# Check the product codes in both msi files ("ProductCode" in the "Property" table).  They have to be the same.  Modify the product code in msi_t if they are not.
+
: Possible optimizations (to reduce the amount of additional disk space):
−
# Create a local pcp file that controls the patch creation process:
+
:*Use only the MSI files of previous releases.  Most of the required information can be extracted from them.  This approach has two disadvantages:
−
## Copy the template.pcp provided by the Windows Installer SDK to, say, aoo_update.pcp.
+
:**MSI files of older releases are not stored anywhere.
−
## Update the properies in its "PatchMetadata" table (basically metadata that describe who updates what and when).
+
:**When files are removed then, to fulfill the patch requirements, the files of the previous release are used instead. These files are contained in the CAB file and are not present in the MSI.
−
## Update some values in the "Properties" table:
+
*Create the patch.
−
##* Set PatchOutputPath to the name of the resulting msp patch file.
+
:This is done by the new Perl script <code>solenv/bin/patch_tool.pl</code>.  It performs four basic steps:
−
##* Set PatchGUID to a newly created UUID.
+
:*For both the previous and the current release unpack the downloadable installation sets (not necessary for the current release) to get access to MSI and CAB files and unpack the CAB file (requirement of the msimsp.exe that will ultimately create the MSP patch.
−
## Add a row to the "ImageFamilies" table with generic data for the msi that is to be patched.
+
:*Check that all requirements (listed above) are fulfilled.
−
## Add a row to the "UpgradedImages" table with generic data for the patch target.
+
:*Set up a PCP file that is basically an MSI with some additional restrictions.  Its tables describe for example the version numbers of previous and current release so that when the patch is applied, Windows can check that the patch is applicable to the installed version of OpenOffice.
−
## Remove the "PatchSequence".
+
:*Run the msimsp.exe program of the Windows SDK with the PCP as driver file.  After about 15 minutes it creates the MSP patch file.
−
# Run MsiMsp.exe on the aoo_update.pcp file.  It creates the msp patch file and log data. For this it compares the set of files contained in the two msi files (but it also expects these files already unpacked from the msi on disk).
+
*Add information about the current release to <code>instsetoo_native/data/releases.xml</code>.
−
# The log data can be converted to human readable form (HTML pages) with the wilogutl.exe command.
+
:The most important part of the information is the URL of where the release can be found on the Apache servers. When the next release is build the <code>releases.xml</code> file can also be used to guess the (then) previous release version.
  
 +
The patch creation mechanism should be able to handle other combinations of source and target versions.  This case is just not handled by the <code>instsetoo_native/util/makefile.mk</code>.  You have to call <code>solennv/bin/patch_tool.pl</code> from the command line and provide <code>--source-version</code> and <code>--target-version</code> options.
  
−
The resulting msp patch file can be run from the Windows file explorer and will turn a previously installed msi_o into a what installation of msi_t would result in.  Well, almost.  Experiments have shown that there are some subtle differences.  One is that the about box still read Apache  OpenOffice 3.4.0 instead of 3.4.1.  But that may be a "feature" of the update mode.
+
===How To Create Patches===
  
−
===Current state===
+
Creating patches is quite simple:
−
Current state of support for creating patches in the OpenOffice build system:
+
*Prepare to build OpenOffice as you usually do.
−
* The <code>make_installer.pl</code> scripts does already have some support for creating msp patches. This feature, however, is not activated and thus can not be triggered by the instsetoo_native makefile.
+
*(Optional but recommended) Provide downloadable installation sets in <code>ext_sources/</code> for the languages you are interested in.
−
* <code>make_installer.pl</code> creates a new and random product code GUID on every run.  This has to be changed for supporting msp patch files.  The product code has to remain constant between updates.  There is already some support for constant product codes (see instsetoo_native/inc_openoffice/windows/msi_templates) but that is not yet active.
+
*(Optional but recommended) Define the previous release number by adding a or modifying the line in <code>instsetoo_native/util/openoffice.lst</code> that defines <code>PREVIOUS_VERSION</code>.  You find it in the <code>variables</code> section of the product which you are building (most likely 'Apache_OpenOffice' and/or 'Apache_OpenOffice_SDK').  For example
 +
    ...
 +
    Apache_OpenOffice
 +
    {
 +
        Settings
 +
        {
 +
            variables
 +
            {
 +
                ...
 +
                PRODUCTVERSION 4.1.0
 +
                PREVIOUS_VERSION 4.0.1
 +
                ...
 +
*Got to <code>instsetoo_native</code> and call <code>build</code> with your favorite options and an additional <code>release=t</code>.  For example
 +
  build --all -P4 -- -P4 release=t
 +
*When that the build has finished go to <code>instsetoo_native/util/</code> and run
 +
  dmake patch-create
 +
:This will produce the MSP files as <code>instsetoo_native/wntmsci12.pro/Apache OpenOffice/msp/VERSION/LANGUAGE/openoffice.msp</code>.  The VERSION part encodes the previous and current version.  For an upgrade from 4.0.1 to 4.1 it would be <code>v-4-0-1_v-4-1-0</code>
 +
*Still in <code>instsetoo_native/util/</code> run
 +
    dmake patch-update-releases-xml
 +
:to create an updated version of the <code>releases.xml</code> file.  Follow the last message in the output to copy the updated file to <code>instsetoo_native/data/</code> and commit it to SVN.
 +
 
 +
===Known Issues===
 +
*Deinstallation of a patch (not deinstallation of a patched OpenOffice) is prevented by the test that checks if OpenOffice is still running.
 +
:Probably caused by <code>IsOfficeRunning()</code> in <code>setup_native/source/win32/customactions/patch/swappatchfiles.cxx</code> which tries to detect if OpenOffice is running by attempting to rename <code>programs/vcl*.res</code>.  A similar test in another file was modified for Vista and above.  Maybe integrating that change will fix this problem.
 +
*After application of a patch Windows asks to reboot to activate changes to registry entries.
 +
:This seems to be caused by ooofilt_x64.dll being in use by the SearchFilterHost.  That prevents the DLL from being updated during patch application.  To update it, Windows has to reboot. (Look for 'Info 1603' in the log file of the patch application).  See also [http://msdn.microsoft.com/en-us/library/aa369779%28v=vs.85%29.aspx Logging of Reboot Requests].
 +
[[Category:Documentation/Building Guide]]

Latest revision as of 14:09, 13 December 2013

Installation packages

The building of installation packages is the last step in building OpenOffice. It is triggered by the makefile.mk in main/instsetoo_native/util/ but most of the work is done by the solenv/bin/make_installer.pl and modules under solenv/bin/modules/installer/. It basically consists of collecting all files that are to be installed and putting them into an archive that can be installed on the targeted operating system. The files and other items like registry entries (only on Windows) are defined as script items in the scp2 module. The installation technique depends on the operating system:

Windows
An MSI that is run by setup.exe. The use of setup.exe allows the installation of some Windows redistributables. It is built as loader2.exe in main/desktop/win32/source/setup/. It runs an upgrade instead of a full installation if
  • an upgrade key read from setup.ini exists in the Windows registry
  • setup.exe finds any .msp files
  • there is an instance of AOO already installed and that matches the product code read from setup.ini.
For the download version the msi and setup.exe are wrapped by an NSIS installer.
Linux
A set of RPM or DEB packages that are installed by distribution specific package managers.
MacOSX
A DMG archive that is (can be?) copied into the /Application directory.

How To Create Installation Sets

Installation sets are created when you run build in instsetoo_native. How to set up the build system is described in the building guide and step by step building guide. When your build system is configured you can build OpenOffice like this: 

   cd main/instsetoo_native
   source ../winenv.set.sh # or another *.[sS]et.sh, the name depends on your platform
   build --all

You can speed up the building process by running it in multiple parallel processes like this 

   build --all -P4 -- -P4

where the numbers depend on how much your CPU can handle and if you still want to work with your computer while you are building. On a 4 core CPU the -P4 -- -P4 option leaves a Linux system responsive while a Windows system starts to lag.

The build command in instsetoo_native/<code> (with or without the <code>--all option) builds installation sets for all languages that where given to configure via the --with-lang option. Without the --with-lang option the set of languages defaults to en-US. There is a second multiplication factor for the installation sets that are built: the package format. The set of package formats depends on the platform. For Windows that is msi, for Linux that is deb and/or rpm and for Mac that is dmg. There is another package format that is available on all platforms. The archive is built by default, but only for en-US, even when more languages where specified via --with-lang.

If you want to build only one installation set for a fixed combination of language and package format then 

   cd instsetoo_native/util
   dmake <target>_<language>.<package>

The list of available targets is listed when you run 

   dmake help

The list of available languages is the one you gave to --with-lang and the list of available package formats is the one explained above (archive, msi, deb, rpm, dmg).

Patches on Windows

A patch differs from a full installation package in that it only contains the modified files. For the update from AOO 3.4 to 3.4.1 this leads to size reduction of roughly 90%.

On Windows there are Windows Installer patches (or .msp files) similar to installation packages (or .msi files). These are self-contained packages that, for example on double-click from the file explorer, perform the update automatically and without the need for further applications.

Windows MSP updates can have three different types (see http://msdn.microsoft.com/en-us/library/windows/desktop/aa370579%28v=vs.85%29.aspx for more details):

  • Small Updates
  • Minor Upgrades
  • Major Upgrades

As small updates do not allow a change of the version number, a minor upgrade is the one the one best suited for Apache OpenOffice updates. A major upgrade should be used for ?.0 releases. While a major upgrade corresponds with our use of .msi files, the creation of minor upgrades requires additional work. On the conceptual level the creation of a minor upgrade is quite simple.

  1. Locate two installation sets, old and new or source and target, both as a pairs of .msi and .cab file. The .msi file is a database with a set of tables that describe the files and registry entries to install. The .cab file contains the actual files.
  2. Create a .pcp file that is basically a data file that drives the patch creation.
  3. Run the MsiMsp.exe command from the Windows installer SDK. This results in a single .msp file.
  4. The .msp can be applied on a computer which has the source installation set installed. The result of that is equivalent to installing the target installation set.

Conditions for creating patches

There are a number of conditions that both source and target installation sets have to fulfill. Breaking this conditions may result in very subtle errors either during the patch creation or application. The conditions are defined on values in tables in the .msi files of source and target installation sets:

  • In the Property table:
    • The values of the UpgradeCode property differ.
      Identical values indicate the same version => no need to create a patch.
    • The values of the ProductCode property are identical.
    • The values of the PRODUCTBUILDID property differ and the newer value is higher than the old value.
  • Adding and deleting files, registry entries, components, features:
    • New files can be added but only to new components in new features.
  • Files and Components (and registry entries?) must not be deleted.
    If a file is not needed anymore than it may be possible to set its size to zero instead of deleting it completely.

jani: would rename be possible ? zero length files are often a problem with backup/copy.
andre:No, the name has to remain unchanged. But maybe we can put one byte into files.

  • For components that exist in the Component table of the old installation set:
    • There is a corresponding component in the new installation set (ie. components must not be deleted).
    • Its ComponentId values do not change.
    • Its Component values do not change.
    • That means that the component names (ie the ComponentId values) do not contain the full AOO version number. Just the major version number would be OK.
    • Maybe: The KeyPath values point to the same files.
  • For registry entries that exist in the Registry table in the old installation set:
    • There is a corresponding registry entry in the new installation set (ie. registry entries must not be deleted).
    • The Registry values do not change.
    • The Key values do not change.
    • That means that the component names (both the Registry and Key values) must not contain the full AOO version number. Just the major version number would be OK.
  • In the File table:
    • The Sequence values remain identical for files that are in both the old and the new installation sets, regardless of whether a file has changes or not.
    • The Sequence values are unique.
    • Probably: The Sequence values form a sequence without holes.

Current state

The patch creation on Windows has been reimplemented. The existing implementation was inactive, incomplete and undocumented and therefore could not be reused.

Workflow

In the typical use case patches are created from the previous version to the currently released version.

The process of creating MSP patches can be broken down into three steps:

  • Build installation sets of OpenOffice with the additional option release=t.
This enforces the conditions that where described above by integrating information about the source release into the build process. This information is taken from downloadable installation sets. These are expected in the ext_sources/ directory. When they are missing (which is the default) then they are downloaded from archive.apache.org. This should not lead to band width problems because release builds usually are made only by the release manager twice a year.
Possible optimizations (to reduce the amount of additional disk space):
  • Use only the MSI files of previous releases. Most of the required information can be extracted from them. This approach has two disadvantages:
    • MSI files of older releases are not stored anywhere.
    • When files are removed then, to fulfill the patch requirements, the files of the previous release are used instead. These files are contained in the CAB file and are not present in the MSI.
  • Create the patch.
This is done by the new Perl script solenv/bin/patch_tool.pl. It performs four basic steps:
  • For both the previous and the current release unpack the downloadable installation sets (not necessary for the current release) to get access to MSI and CAB files and unpack the CAB file (requirement of the msimsp.exe that will ultimately create the MSP patch.
  • Check that all requirements (listed above) are fulfilled.
  • Set up a PCP file that is basically an MSI with some additional restrictions. Its tables describe for example the version numbers of previous and current release so that when the patch is applied, Windows can check that the patch is applicable to the installed version of OpenOffice.
  • Run the msimsp.exe program of the Windows SDK with the PCP as driver file. After about 15 minutes it creates the MSP patch file.
  • Add information about the current release to instsetoo_native/data/releases.xml.
The most important part of the information is the URL of where the release can be found on the Apache servers. When the next release is build the releases.xml file can also be used to guess the (then) previous release version.

The patch creation mechanism should be able to handle other combinations of source and target versions. This case is just not handled by the instsetoo_native/util/makefile.mk. You have to call solennv/bin/patch_tool.pl from the command line and provide --source-version and --target-version options.

How To Create Patches

Creating patches is quite simple:

  • Prepare to build OpenOffice as you usually do.
  • (Optional but recommended) Provide downloadable installation sets in ext_sources/ for the languages you are interested in.
  • (Optional but recommended) Define the previous release number by adding a or modifying the line in instsetoo_native/util/openoffice.lst that defines PREVIOUS_VERSION. You find it in the variables section of the product which you are building (most likely 'Apache_OpenOffice' and/or 'Apache_OpenOffice_SDK'). For example 
   ...
   Apache_OpenOffice
   {
       Settings
       {
           variables
           {
               ...
               PRODUCTVERSION 4.1.0
               PREVIOUS_VERSION 4.0.1
               ...
  • Got to instsetoo_native and call build with your favorite options and an additional release=t. For example 
  build --all -P4 -- -P4 release=t
  • When that the build has finished go to instsetoo_native/util/ and run 
  dmake patch-create
This will produce the MSP files as instsetoo_native/wntmsci12.pro/Apache OpenOffice/msp/VERSION/LANGUAGE/openoffice.msp. The VERSION part encodes the previous and current version. For an upgrade from 4.0.1 to 4.1 it would be v-4-0-1_v-4-1-0
  • Still in instsetoo_native/util/ run 
   dmake patch-update-releases-xml
to create an updated version of the releases.xml file. Follow the last message in the output to copy the updated file to instsetoo_native/data/ and commit it to SVN.

Known Issues

  • Deinstallation of a patch (not deinstallation of a patched OpenOffice) is prevented by the test that checks if OpenOffice is still running.
Probably caused by IsOfficeRunning() in setup_native/source/win32/customactions/patch/swappatchfiles.cxx which tries to detect if OpenOffice is running by attempting to rename programs/vcl*.res. A similar test in another file was modified for Vista and above. Maybe integrating that change will fix this problem.
  • After application of a patch Windows asks to reboot to activate changes to registry entries.
This seems to be caused by ooofilt_x64.dll being in use by the SearchFilterHost. That prevents the DLL from being updated during patch application. To update it, Windows has to reboot. (Look for 'Info 1603' in the log file of the patch application). See also Logging of Reboot Requests.
Retrieved from "https://wiki.openoffice.org/w/index.php?title=Building_installation_packages&oldid=232431"
Personal tools