Windows Installer patches and upgrades

Hi,

I have been looking into what modifications would be
required to be able
to use the Windows Installer ("MSI") patch and
upgrade mechanisms for
upgrading OO.o installations. (Either just security or
bugfix -type
patches that affect just a few files, or if feasible, why
not also
upgrades like 2.0.4->2.1.0 (or whatever the next version
will be).)

When the OO.o MSI installation system was designed, did any
thought go
into supporting upgrades? It seems to me that there are
related code
snippets here and there in the Perl modules that have been
commented
out. Was this something that was tried and pondered, but
then skipped?
or just random experimentation?

Are there some design documents available that would contain
the
rationale why stuff is done as it is currently? Did it turn
out to be
way too hard to support Windows Installer -managed upgrades?
Or was it
just something that didn't fit in with the upgrade methods
used on
Solaris and/or Linuxes?

Here are some thoughts that I wrote up after looking into
these issues.
Please discuss... I have attempted to direct follow-ups to
devinstallation.openoffice.org but don't know whether
that will survive
through the mailing list; if you aren't a member of that
and want to
follow-up, you should subscribe.

Windows Installer has a binary patch mechanism. From a
high-level point
of view, it seems to provide the features we would need.
Unfortunately,
though, the way the OO.o Windows Installer installer is
built clashes
with varous requirements for using Windows Installer
patching...

The build creates a new ProductCode (a GUUID) each time one
builds an
installer, no matter how small (or zero) the change from the
previous
build is. This is done despite the source contains a file
(instsetoo_native/inc_openoffice/windows/msi_templates/codes
.txt) with
predefined GUUIDs to use as ProductCodes for different
languge
installers.

The code to use the codes.txt file is commented out in
solenv/bin/modules/installer/windows/msiglobal.pm. If
uncommented (and
correspondingly the code to generate a fresh ProductCode is
removed),
things do work. There is no explanation why this code has
been commented
out. Was it found to cause trouble?

More seriously, the build generates new ComponentIds (also
GUUIDs) each
time an installer is built. The word "component"
here is used in the
Windows Installer sense, not OO.o sense (Writer, Calc, etc).
The OO.o
Windows Installer installer contains around a thousand
components, each
component containing from one to some dozen files.)

Again, if one digs into the Perl code that is used to direct
the
installer construction, there are remains of code to save
the component
IDs generated and reuse them in sequential builds. But
effectively that
doesn't happen now. Whether this is just some idea that
never got fully
implemented, or something that was originally designed to be
used, but
was found not to work, I have no idea. Whether component IDs
should be
reused "globally" from an official list kept in
the upstream sources, or
just reused by each vendor building MSI OO.o installers, I
can't say. 

Probably both the ProductCode and ComponentIds should be
per-vendor, not
shared by all who produce OO.o builds for Windows.

When applying an upgrade that contains (binary) patches,
Windows
Installer obviously needs to be sure that it is applying the
patch to
the correct file, and not one that has been replaced or
tampered with
on the end-user machine trough some other mechanism. For
files that are
"versioned" (contain version resource blocks,
i.e. DLL and EXE files),
Windows Installer trusts that version, and knows whether the
patch is
applicable based on the version resource block.

For unversioned files, Widnows Installer either needs to
apply the patch
to the file from the installation "source" (i.e.
the CD, or a network
share), or it needs to be able to verify that the file
indeed is the
correct one corresponding to the patch.

The first alternative, requiring the original installation
source, is
obviously not acceptable. The second alternative requires a
separate
table, MsiFileHash, in the original MSI database.
MsiFileHash contains
128-bit hashes for unversioned files. OK, generating that is
no problem,
it is pretty easy to add code that uses the Win32::API Perl
module to
solenv/bin/modules/installer/windows/file.pm to calculate
the hashes
(using the MsiGetFileHashA() function) and create the
MsiFileHash table.

But then we come across yet another problem: The versions of
the files
in the File table. Currently the OO.o MSI database uses the
same version
number for all files. In ood680-m2 the version is
8.0.4.9064, where the
first three numbers correspond to the product version, 8.0.4
meaning
OO.o 2.0.4. The "8" apparently comes from the
StarOffice version
numbering. The "9064" is the upstream
"build number" (not to be confused
with some numbering of actual builds by a vendor, or a
developer on a
certain machine), and corresponds to a milestone. 9064
corresponds to
ood680-m2.

File versions in Windows Installer are just four numbers.
Upgrading a
file managed by Windows Installer means its version must
increase. But
with versions like 8.0.4.9064 that already are four numbers,
there is no
space for bumps corresponding to patches "on top
of" the same
milestone. 

Oh well, assuming that the second and third version numbers
never get
very high, one obvious workaround for this is to combine
them so that we
would have 8.100*0+4.9064.0 = 8.4.9064.0 for an original
file from
ood680-m2, and then 8.4.9064.1 for one that has been patched
once, etc.
For OO.o 2.1.0, the version would be 8.100.buildnumber.0
originally,
etc.

Cheers,
--tml


------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribeinstallation.openoffice.org
For additional commands, e-mail: dev-helpinstallation.openoffice.org