I have just checked in what basically is a reimplementation of the
defunct support for creating patches on and for Windows.
Building OpenOffice without the new "release=t" flag should work like
before. If you don't plan to build patches then you can stop reading
now (just tell me if your builds break).
Support for patch creation is still in its early stages. It may or may
not work. Having said that, I would not mind if you would try it out,
just don't apply them yet outside a virtual machine. At the moment I am
interested to get the workflow right and reliably working. It is a
lengthy process, something in the area of 30 minutes per language, and I
can make only so many test runs. But you don't have to run it to point
out how to improve the workflow.
Here is how I currently think how patch creation can work. Note that
patch creation is something that I expect is only done once per release
by the release manager (or whoever builds the release installation
sets.) It may sound very technical but it really list only the most
important points.
0. Expected (disk) space and time requirements:
Disk space: Number of languages *
- Previous downloadable installation set (EXE) in ext_sources/
- The above unpacked in instsetoo_native/wntmsci12.pro
- The CAB file of the above (maybe 95% of the installation set) unpacked
- The installation set and downloadable installation set of the
current release
- A copy of the above, arranged so that msimsp.exe can process it.
- The MSP patch, about 10% of the downloadable installation set.
I did not measure it but I would estimate the total to be around 500 MB
Time:
- Download previous installation set from archive.apache.org (use a
local cache if you can)
- Unpack the above
- Unpacke the CAB inside the above
- Build the installation set of the current version
- Make a local copy of the above
- Run msimsp.exe
All in all about 30 minutes
1. Prepare the release builds (one per language) that are compatible
with the previous release.
Why: There are a lot of conditions to fulfill before you can create a
patch between two installation sets.
One is that files must not be deleted.
Another is that files keep the same internal data (unique name, sequence
number, etc.)
These conditions have to be checked and enforced.
How: Go to main/instsetoo_native and run 'build release=t'
This flag should probably be added as option to configure. It is not
used outside of instsetoo_native but it is important that it is not
forgotten when the installation sets are built.
What: In order to check the conditions, solenv/bin/make_installer.pl
(which is called by build/dmake from instsetoo_native) needs access to
the previous release.
It does that by reading the necessary data from the previous
installation sets. For that
a) the downloadable installation set is downloaded from archive.apache.org
If you are concerned about too many downloads from archive.apache.org:
- Creating patches is typically done twice a year, by the release
manager
- You can provide a local repository. This also speeds up this step.
b) the downloadable installation is unpacked to get access to its
content, most importantly (in this stage) the MSI file.
For this I use 7zip, the only program I know of, that is able to
unpack the installation set EXE that is created by the NSIS tool.
c) use the msidb.exe program from the Windows SDK to read the database
tables in the MSI
2. Store information about the new release for when we will be creating
patches when doing the next (future) release.
Why: The current release will eventually be the previous release.
How: The tool is not checked in, I am still cleaning it up a bit.
What: This extends the main/instsetoo_native/data/releases.xml list with
data about the current release.
3. Create the patches (one per language)
How: Go to main/instsetoo_native/util and run 'dmake patch_create'
What:
a) Check if the installation sets for the relevant languages are present
(both the previous and current ones)
b) Check that all conditions (that I know of) are fulfilled.
Patch creation will break when even one condition is not met.
It will, for example, detect when the release builds where not made
with the "release=t" flag.
c) Create a local copy of the current release.
This is necessary because the msimsp.exe tool (the one that creates
the actual patch file) needs the CAB file (the container that contains
all files that are to be installed) and its unpacked content in the same
directory.
d) Run the msimsp.exe tool to create the patch file.
Creating an installation set, unpacking and copying the previous and
current ones, are already lengthy processes that each can take several
minutes to complete.
Msimsp.exe usually takes 10 to 15 minutes to run.
4. (For testing) Apply the patch
Why: To verify that the created patch really works
Attention:
While steps 1 to 3, if they fail, only waste time and disk space
(disk space can be reclaimed by deleting instetoo_native/wntmsci12.pro,
the time is gone forever), installing the MSP patch can break your
Windows registry.
It has not happend to me but it is a possiblity. Try this in a virtual
machine.
How: Find the MSP file at
main/instsetoo_native/wntmsci12.pro/Apache_OpenOffice/msp/v-4-0-1_v-4-1-0/<language>/msp/openoffice/msp
A double click should work.
Alternatively run "msiexec.exe /update c:\\...\\openoffice.msp
REINSTALLMODE=omus", note that the path to openoffice.msp has to be in
Windows notation, even when you run msiexec from a cygwin shell.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
