Hallo @allda die Fragen nach dem Installer/Patches/Updates immer wieder mal auftauchen leite ich Euch mal Ingos Antwort au die Frage von tml auf der internationalen Liste weiter.
Gruss Marko -------- Original-Nachricht -------- Betreff: Re: [installation-dev] Windows Installer patches and upgrades Datum: Tue, 19 Sep 2006 11:22:47 +0200 Von: Ingo Schmidt <[EMAIL PROTECTED]> Antwort an: dev@openoffice.org CC: dev@openoffice.org Newsgruppen: gmane.comp.openoffice.devel.general Referenzen: <[EMAIL PROTECTED]> Hi tml, you are absolutely right. The code contains many parts, that were required for preparation of Windows patch/update mechanisms. Unfortunately all tests showed, that the patch/update mechanism of Windows Installer is not reliable enough or does not fit to our requirements. Therefore we have chosen the Major Upgrade as the standard update mechanism for OpenOffice.org. This means, that a newer installation first removes an old installation and than installs itself. Of course there are some requirements, that are probably only necessary for StarOffice, not for OpenOffice.org. Therefore it could be interesting, to find out, what the exact OOo patch/update requirements are. Do we want to have one patch for each language? Do we want to have cumulative patches? Do we need different patches for different base versions? Additionally the patch creation process was not very nice. We made some tests, creating a msp file as the difference of two administrative installation sets with the help of a Patch Creation Property file (pcp). But when there were hundreds of different files in both installation sets, the result was not usable. Some more comments in your text:
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?
See above.
Here are some thoughts that I wrote up after looking into these issues. Please discuss... I have attempted to direct follow-ups to dev@installation.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?
Exactly. It made much trouble and did not fit to our requirements.
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, orjust reused by each vendor building MSI OO.o installers, I can't say.
The OOo component codes should be stored in the file instsetoo_native/inc_openoffice/windows/msi_templates/components.txt If new components were created, the new codes were added to this file automatically (the problem how to commit this file was still open). But nevertheless we were not able to create reliable patches with this process and due to lack of time we did not use it.
Probably both the ProductCode and ComponentIds should be per-vendor, not shared by all who produce OO.o builds for Windows.
That would be the next step.
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.
Sounds good.
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.
The versions of the files in the file table are only a trick, to guarantee, that the Major Upgrade works. The 8 comes from StarOffice, but this number is arbitrary, because we do not use this mechanism in StarOffice.
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 samemilestone.
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.
It should be no problem, to change this number to a more useful versioning schema. We only have to guarantee, that it is increased for Major Upgrades. And it should be also simple to use the MsiFileHash table. It would be nice, if we could work together, to find a solution for usable OOo patches using Windows Installer techniques. Until now, I have only seen Windows Installer patches for OOo, that were created by commercial tooling. But here we need a process, that can create msp files automatical and reliable within this Perl packaging process. Greetings Ingo --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
