Windows Installer patches and upgrades

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
> 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?

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, or
> just 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/compon
ents.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 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.
> 

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: dev-unsubscribeinstallation.openoffice.org
For additional commands, e-mail: dev-helpinstallation.openoffice.org

ti 2006-09-19 klockan 11:22 +0200 skrev Ingo Schmidt:

> Unfortunately all tests showed, that the patch/update
mechanism of 
> Windows Installer is not reliable enough 

Ah, that would be a pity. I am only in the experimentation
and testing
stage for now. I have to do more experimentation before I
know whether
to agree with your conclusion. 

Being able to prepare Windows Installer patches will require
a thorough
documentation of the procedure, of course.

> or does not fit to our 
> requirements. [...] 
> Of course there are some requirements, that are
probably only necessary 
> for StarOffice, not for OpenOffice.org.

Probably... And then again the Novell Edition for Windows
does some
things differently and has different requirements than the
community
build. (Most obviously, we use ooo-build, and we build a
multi-language
installer for most of the non-CJK languages we support,
having separate
language pack installers only for the CJK languages, and
languages
without Windows localisation.)

> But when there were hundreds of different files in both
installation 
> sets, the result was not usable.

Do you have any more detailled memory of what made it
unusable? Didn't
Windows Installer cope with many patches in one .msp? Did it
just stop
working, hang or something? Or did you get some clear error
messages
saying that the .msp is too complex?

> It would be nice, if we could work together, to find a
solution for 
> usable OOo patches using Windows Installer techniques.

Yep, I agree. Once I have something that I think has a
chance of being
accepted (and I am reasonable certain that producing MSI
patches will be
feasible) I will submit it upstream.

--tml


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

ti 2006-09-19 klockan 11:22 +0200 skrev Ingo Schmidt:

> Unfortunately all tests showed, that the patch/update
mechanism of 
> Windows Installer is not reliable enough 

Ah, that would be a pity. I am only in the experimentation
and testing
stage for now. I have to do more experimentation before I
know whether
to agree with your conclusion. 

Being able to prepare Windows Installer patches will require
a thorough
documentation of the procedure, of course.

> or does not fit to our 
> requirements. [...] 
> Of course there are some requirements, that are
probably only necessary 
> for StarOffice, not for OpenOffice.org.

Probably... And then again the Novell Edition for Windows
does some
things differently and has different requirements than the
community
build. (Most obviously, we use ooo-build, and we build a
multi-language
installer for most of the non-CJK languages we support,
having separate
language pack installers only for the CJK languages, and
languages
without Windows localisation.)

> But when there were hundreds of different files in both
installation 
> sets, the result was not usable.

Do you have any more detailled memory of what made it
unusable? Didn't
Windows Installer cope with many patches in one .msp? Did it
just stop
working, hang or something? Or did you get some clear error
messages
saying that the .msp is too complex?

> It would be nice, if we could work together, to find a
solution for 
> usable OOo patches using Windows Installer techniques.

Yep, I agree. Once I have something that I think has a
chance of being
accepted (and I am reasonable certain that producing MSI
patches will be
feasible) I will submit it upstream.

--tml


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

ti 2006-09-19 klockan 11:22 +0200 skrev Ingo Schmidt:

> Unfortunately all tests showed, that the patch/update
mechanism of 
> Windows Installer is not reliable enough 

Ah, that would be a pity. I am only in the experimentation
and testing
stage for now. I have to do more experimentation before I
know whether
to agree with your conclusion. 

Being able to prepare Windows Installer patches will require
a thorough
documentation of the procedure, of course.

> or does not fit to our 
> requirements. [...] 
> Of course there are some requirements, that are
probably only necessary 
> for StarOffice, not for OpenOffice.org.

Probably... And then again the Novell Edition for Windows
does some
things differently and has different requirements than the
community
build. (Most obviously, we use ooo-build, and we build a
multi-language
installer for most of the non-CJK languages we support,
having separate
language pack installers only for the CJK languages, and
languages
without Windows localisation.)

> But when there were hundreds of different files in both
installation 
> sets, the result was not usable.

Do you have any more detailled memory of what made it
unusable? Didn't
Windows Installer cope with many patches in one .msp? Did it
just stop
working, hang or something? Or did you get some clear error
messages
saying that the .msp is too complex?

> It would be nice, if we could work together, to find a
solution for 
> usable OOo patches using Windows Installer techniques.

Yep, I agree. Once I have something that I think has a
chance of being
accepted (and I am reasonable certain that producing MSI
patches will be
feasible) I will submit it upstream.

--tml


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