Procedure to produce incremental patch for the NovellWin32ISO
installers. This is somewhat hard to automate. This document is very
much a work in progress, written and updated while working out how
this actually should be done. Read with a large pinch of salt.

The NovellWin32ISO builds are identified by the full three-part
PACKAGEVERSION from openoffice.lst (2.0.4, for instance) suffixed by a
dash and an counter, starting from 1 in the first build. The first
distributed NovellWin32ISO build of 2.0.4 is thus 2.0.4-1.

The "PATCHLEVEL" we talk about below is a NovellWin32ISO concept, not
to be confused with other things related to "patching" that might have
similar names in the upstream installer-building Perl code (much of
which is undocumented, and even probably unfinished, or remains of
procedures never fully implemented, or whatever). So when you see
mentions of patching and updating in solenv/bin/modules/installer/*.pm
etc, note that this has nothing to do with the Windows Installer
patching stuff described here.

For the first build, build 1, PATCHLEVEL is 0. For build 2 it is 1,
etc. Yeah, this is illogical, I should have called the first build
2.0.4-0.

The idea is that the original build directory is kept, and only
incremental changes are done. Only those projects where there has been
code changes (i.e. updated ooo-build patches that affect the project)
since the previous build are rebuilt. Thus the files that are included
in each build's installer are mostly from the original build, only
those that have actual changes are fresher.

- Rename build/$tag/instsetoo_native/wntmsci10.pro/OpenOffice to
OpenOffice-$previous (where $previous is the previous build
counter). Ditto for OpenOffice_languagepack, although I don't think
there would be any point in producing Windows Installer patch
installers for language packs.

- Add a new marker to ChangeLog indicating at which stage this build
was done.

- edit novell-win32-vrb-branding.diff, increment the PATCHLEVEL
value. This means that DLLs built from now on (once the patch is
applied) will get a new version number.

- Run make patch.apply

- Run sh doc/AUTOGEN.NovellWin32ISO.sh. Run make and interrupt it when
it starts the main build with "Building project solenv", i.e. after
having done the upstream configure script and set_soenv stuff.

- Inspect ChangeLog entries since the last marker. Go to build/$tag,
source winenv.set.sh. In each project directly affected by changes
since the last marker, to a build && deliver. Be careful to do this in
the correct order in case a patch since the last release build has
changed the API of some project, but I sure hope that won't happen.

For 2.0.4-2 vs. 2.0.4-1, the projects affected by patches changed seem
to be, in a hopefully correct order:

officecfg
sfx2
sc
binfilter (but nothing that affected what gets built had changed)
helpcontent2

Note carefully what changed/new files get delivered, just for
double-checking later.

- Remove sfx2/wntmsci10.pro/about.obj and do a build && deliver in
sfx2, too.

- Go to instsetoo_native and do a the build there. Edit
util/makefile.mk to avoid building language packs.

- do an administrative install of previous build, and of what you just
built:

  cd build/OOO_2_0_4/instsetoo_native/OpenOffice-1/msi/install/en-US_ar_cs_blabla
  msiexec /a openofficeorg20.msi

  cd build/OOO_2_0_4/instsetoo_native/OpenOffice/msi/install/en-US_ar_cs_blabla
  msiexec /a openofficeorg20.msi

for instance, for 2.0.4-1 and 2.0.4-2: install into
c:\tmp\OOo-2.0.4-1-admin and c:\tmp\OOo-2.0.4-2-admin

- make a new folder for the patch installer, for instance
c:\tmp\OOo-2.0.4-1-2-patch.

Note that a Windows Installer patch can contain several patch pairs;
for instance, we can eventually have a single patch (.msp file) that
patches 2.0.4-1 to 2.0.4-4, 2.0.4-2 to 2.0.4-4, and 2.0.4-3 to
2.0.4-4. For simplicity, below I talk just about a patch for one
update, from 2.0.4-1 to 2.0.4-2.

- create a Patch Creation Properties (.pcp) file, for instance
openofficeorg20.pcp. Copy the
Samples/SysMgmt/Msi/Patching/TEMPLATE.PCP file from the Platform SDK.
A dump of the relevant tables in that file for the 2.0.4-1 to 2.0.4-2
patch is included below. Remember to generate a new GUID for the patch
in the PatchGUID property in the Properties table.

- run msimsp to find the differences between the two above
installations, verify that the DLL and EXE files that have changed
indeed have the updated version in their VRBs.

  msimsp -s openofficeorg20.pcp -p openofficeorg20.msp -l logfile.log

Read the logfile looking for which files have changed

msimsp will not yet actually produce a good enough .msp file. The
ProductVersion properties in the two .msi databases are the
same. Increment the ProductVersion of the .msi file in the "upgraded"
administrative installation.

For instance, for 2.0.4-1, the ProductVersion property is 2.0.9073,
and for 2.0.4-2 this should be then manually incremented to
2.0.9074. Some typical MS braindamage here: The ProductVersion
property is three digits: uchar.uchar.ushort, i.e. the first two <=
255, the last <= 65535. So we can't use the same kind of version
number as for the FileVersion column in the File table, which is four
ushorts, and constructed as

 OOO_MAJOR . OOO_MINOR*100+OOO_MICRO . BUILDID . PATCHLEVEL

For files that are changed in 2.0.4-2, that would be 2.4.9073.1. This
sucks, yeah. But just incrementing the last part (buildid) hopefully
won't cause any trouble, even though it is misleading, as the real
buildid of course is the same for all NovellWin32ISO 2.0.4-x
builds. (Recall that "buildid" in OOo means a number corresponding to
the milestone, it has nothing to do with actual "builds" by
distributors of OOo, like NovellWin32ISO builds. For the milestone
OOO_2_0_4 the OOo buildid is 9073.)

Hmm, even though documentation says that the ProductVersion property
should be three parts as above (uchar.uchar.ushort), in reality many
of the .msi files out there, even from Microsoft, have four-part
ProductVersion properties. The Value column in the Property table is a
string, so there is nothing in the MSI format that prevents this,
although it is of course questionable how Windows Installer accepts
other that three-part ProductVersion properties. Oh well...

- edit the corresponding rows (updated DLLs, EXEs, and nonversioned
files) in openofficeorg20.msi in the second administrative
installation, change the final number of the FileVersion rows in the
File table to the patchlevel in question.

Actually, I don't know whether this is essential or not. It seems that
Windows Installer is happy to apply patches to files even if the
FileVersion doesn't change. For versioned files (DLLs and EXEs) I
guess it is best if the version of the file recorded in Windows
Installer is the same as the one in the file's VRB block, though.

- run msimsp again

- verify that the changed files are indeed exactly those for which you
edited the FileVersion, no more, no less.

================

Exports (.idt files) of the non-empty tables in the Patch Creation
Properties (.pcp) file used when creating the 2.0.4-1 to 2.0.4-2
patch:

==> ImageFamilies:

Family	MediaSrcPropName	MediaDiskId	FileSequenceStart	DiskPrompt	VolumeLabel
s8	S72	I2	I2	S128	S32
ImageFamilies	Family
OOo	OOoSrcPropName	100	11000		

==> PatchMedatada:

Company	Property	Value
S72	s72	l0
PatchMetadata	Company	Property
	AllowRemoval	1
	Classification	update
	CreationTimeUTC	2006-11-21 17:00
	Description	2.0.4-1/2
	DisplayName	2.0.4-1/2
	ManufacturerName	Novell, Inc.
	MoreInfoURL	http://www.novell.com
	TargetProductName	OpenOffice.org 2.0.4

==> Properties:

Name	Value
s72	L0
Properties	Name
AllowProductCodeMismatches	1
AllowProductVersionMajorMismatches	1
ApiPatchingSymbolFlags	0x00000000
DontRemoveTempFolderWhenFinished	1
IncludeWholeFilesOnly	0
ListOfPatchGUIDsToReplace	
ListOfTargetProductCodes	*
MinimumRequiredMsiVersion	300
PatchGUID	{494B0178-4FA5-4AE6-B58E-5B433DD64A92}
PatchOutputPath	openofficeorg20.msp
SEQUENCE_DATA_GENERATION_DISABLED	1

==> TargetImages:

Target	MsiPath	SymbolPaths	Upgraded	Order	ProductValidateFlags	IgnoreMissingSrcFiles
s13	s255	S255	s13	i2	S16	i2
TargetImages	Target
2p0p4d1	c:\tmp\OOo-2.0.4-1-admin\openofficeorg20.msi		2p0p4d2	1		0

==> UpgradedImages:

Upgraded	MsiPath	PatchMsiPath	SymbolPaths	Family
s13	s255	S255	S255	s8
UpgradedImages	Upgraded
2p0p4d2	c:\tmp\OOo-2.0.4-2-admin\openofficeorg20.msi			OOo
