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
[email protected] 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
