[wpkg-users] Package upgrade and checks

[heiko.helmle at horiba.com]

Hello Marc,

Sorry , the patch is "experimental" at best. Use only if you're the 
adventurous type (and mail problems with it directly to me). Or better use 
one of Rainer's suggestions.

But thanks for getting the discussion started :)

Hello Rainer

Thank you very much for your explanation.

> So checking if the version to be upgraded to is already installed 
> (as suggested by checkpolicy=always) is useful only if the package 
checks include a check
> which is true only for a specific version. Else this check will be true 
also
> when doing an upgrade and the upgrade will never be performed.

This is true - and two facts make this easy: WPKGs ability to match RegEx 
in uninstall checks (which is not documented, but works fine) and the very 
fine work you did on "versiongreaterorequal".

> 
> For example:
> Currently installed: Pidgin 2.6.5
> New version: Pidgin 2.6.6
> 
> Checks for: Uninstall entry "Pidgin"
> 
> If checpolicy=always is enabled this will make WPKG not to perform any 
upgrade
> since the check for "Pidgin" uninstall entry is true for every 
> version. So users
> will stay at version 2.6.5.

You're right - this would have to be
<check type="uninstall" condition="versiongreatororequal" path="Pidgin 
[.\d]+" value="2.6.6" />

this works pretty well. Additionally you prevent WPKG from accidentally 
downgrading a package and the installer will only be run when it is 
actually needed (assuming you don't want to downgrade).

[...]
> Next you might claim that you can specify the version to be greater 
> or equal to
> 2.6.5. This would work in both cases (if user is at 2.6.5 and if he 
already
> upgraded to 2.6.6). But it might fail if admins decide to roll out 
> version 2.6.6
> and the user already installed any eventually available newer 
> version (like 2.6.7).

Well actually it helps me - I can decide via check if I want to downgrade 
all users or if I only want to upgrade users on an old version. This was 
actually my intention for the patch, since the primary reason for the 
roll-out was security updates. If I want to force 2.6.6 - including 
downgrades - , I'll just check with "versionequalto".
Additionally many packages (MSIs also) do take very long - even if they 
don't do anything - and users hate waiting while booting. I wrapped the 
patch up while the Lotus Notes installer was thinking about whether it had 
to do anything or not. 

> As a conclusion this checkpolicy=always attribute is very likely to 
> lead to many support requests and problems since most WPKG users are not 
defining such
> detailed checks but rather relying on simple uninstall entry exist 
checks. In
> such cases upgrades would not be performed at all if 
> checkpolicy=always is used.

True. If committed (not probable I guess), the documentation should 
clearly mention that you need _detailed_ check policies.

> On the other hand there is a very simple solution for the problem 
outlined by
> Marc Hennes. Just define the exit code indicating that a newer version 
is
> already installed as a successful exit code in the package definition. 
So WPKG
> will know the update was successful, then WPKG will also run the checks 
to
> verify the system state and then (if checks succeed) just accept 
thepackage to
> be installed properly.

Hmm... This is even harder to test than detailed check policies... I kinda 
like this more:

> Another very simple solution is to call a simple cmd script by WPKG 
> (instead of the installer directly) where the cmd script performs some 
> application-specific checks and either just exits with a defined code 
(e.g. 0: installed
> successfully, 1: installation failed, 2: already installed ...) 
> depending on the action it really performed.

... but this defeats the reason of <check> altogether if you outsource it 
into an external script anyway. I'd rather have all my checks in <check> 
and all my install commands in <install>.

> I am just not a friend of introducing thousands of switches which makes 
WPKG
> complex, difficult to test and understand for the user. For exampel the
> checkpolicy=always switch would require quite a lot of new test 
> cases to verify
> its function with packages with "generic" checks (e.g. uninstall entry 
with no
> version number), with "detailed" checks (e.g. uninstall check with 
version
> number), where user already installed a newer version, where user did 
not
> install a newer version etc.

You're right - the admin needs to be aware, that checkpolicy=always _will_ 
need detailed checks. That's why the patch didn't make it a default. Using 
RegEx in the uninstall checks is nearly mandatory, as is thorough use of 
"versiongreaterorequal". It does save you from a lot of extra scripting 
though - and might mean less work in the future.

I don't really like the many scripts you need to get to the same place 
that I got to with "checkpolicy" - (yes, it's a shortcut). Most of the 
packages I rolled this way don't need an external script at all. They 
simply don't do anything if there's no need to. And my users stopped 
asking questions like "Why did you reinstall the JRE when it was already 
updated nicely?"

> In addition there is an extremely small amount of software packages 
where this
> specific switch makes any sense and the potential that WPKG users will 
not
> understand it is quite high. So users will impose support effort by 
asking for
> its functionality or even worse use it wrongly and end up with 
non-updated
> systems (see example above).

I don't know if you're right here. I guess with proper documentation, this 
switch might be pretty useful. 
And there's other things in WPKG that are more confusing (like reboot=true 
having different meanings in <package> and <exit>)

In a controlled environment (enduser doesn't install software), you won't 
need that - but at least my environment is not that controlled.

> Moreover most installers behave nicely when an installation of an 
already
> installed version is performed. They just abort installation and 
> report success or a specific exit code.

I think this is a long shot. Every Installer does things differently and 
you have to test each and everyone (which, in my opinion, is more effort 
than thoroughly testing your own checks). For example Firefox does 
rigorously downgrade your installation if you happen to deploy an old 
installer (?security nightmare?). Java JRE will install alongside the 
current JRE a "static" installation if there's already a newer one. 
Moreover, this only applies for J6RE Update 10+, not the smaller ones.

I'd rather write a sophisticated uninstall check than testing all 
installers how they behave. Every installer behaves differently - but 
<check> is pretty predictable.

[...]
> For more advanced users a simple cmd script which performs 
pre-installation
> checks might be used. Usually simple scripts like this should do the 
trick:
> 
> install-software.cmd:
> ----
> @echo off
> 
> reg query HKLM\.... | findstr "<version>"
> :: already installed
> if %ERRORLEVEL% EQU 0 exit 0
> :: version mismatch
> start /wait "installer" <installer> <switches>
> ----

Hmm... that makes me missing out on the very excellent checks WPKG already 
has.

I understand that you don't want to have "checkpolicy". Its use (which is 
not default for a good reason) needs the admin to define really "good" 
(not "catchall") package checks. But the benefit is much less code in the 
actual package definition, less external scripting, less dependencies to 
manage. And you can do stuff like this:

                <check type="logical" condition="or">
                        <check type="uninstall" 
condition="versiongreaterorequal" path="Adobe Flash Player 10 ActiveX" 
value="10.0.45.2" />
                        <check type="logical" condition="not">
                                <check type="uninstall" condition="exists" 
path="Adobe Flash Player 10 ActiveX" />
                        </check>
                </check>

                <download url="http://<wpkg-server>/Adobe 
Flash/install_flash_player_ax-10.0.45.2.exe" 
target="wpkg-installers\install_flash_player_ax.exe" />
                <install 
cmd='"%TEMP%\wpkg-installers\install_flash_player_ax.exe" /S' />
                <upgrade 
cmd='"%TEMP%\wpkg-installers\install_flash_player_ax.exe" /S' />

Which means "Install Flash Player if (and only if) a version is installed 
older than x.x.x.x". And more importantly "Don't install Flash if this 
computer is Flash-free".  You can refire this package every patch cycle, 
just by bumping the revision and version number. and the <install> is one 
single line, no external scripts.

If you don't mind, I'll try to keep the patch in the bugzilla bug updated 
with new wpkg revisions.

Best Regards
        Heiko Helmle
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.wpkg.org/pipermail/wpkg-users/attachments/20100422/67bd2e01/attachment-0002.html>