<tt><font size=2>Hello Marc,</font></tt>
<br>
<br><tt><font size=2>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.</font></tt>
<br>
<br><tt><font size=2>But thanks for getting the discussion started :)</font></tt>
<br>
<br><tt><font size=2>Hello Rainer</font></tt>
<br>
<br><tt><font size=2>Thank you very much for your explanation.</font></tt>
<br>
<br><tt><font size=2>> So checking if the version to be upgraded to
is already installed <br>
> (as suggested by checkpolicy=always) is useful only if the package
checks include a check<br>
> which is true only for a specific version. Else this check will be
true also<br>
> when doing an upgrade and the upgrade will never be performed.<br>
</font></tt>
<br><tt><font size=2>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".</font></tt>
<br>
<br><tt><font size=2>> <br>
> For example:<br>
> Currently installed: Pidgin 2.6.5<br>
> New version: Pidgin 2.6.6<br>
> <br>
> Checks for: Uninstall entry "Pidgin"<br>
> <br>
> If checpolicy=always is enabled this will make WPKG not to perform
any upgrade<br>
> since the check for "Pidgin" uninstall entry is true for
every <br>
> version. So users<br>
> will stay at version 2.6.5.</font></tt>
<br>
<br><tt><font size=2>You're right - this would have to be</font></tt>
<br><tt><font size=2><check type="uninstall" condition="versiongreatororequal"
path="Pidgin [.\d]+" value="2.6.6" /></font></tt>
<br>
<br><tt><font size=2>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).</font></tt>
<br>
<br><tt><font size=2>[...]<br>
> Next you might claim that you can specify the version to be greater
<br>
> or equal to<br>
> 2.6.5. This would work in both cases (if user is at 2.6.5 and if he
already<br>
> upgraded to 2.6.6). But it might fail if admins decide to roll out
<br>
> version 2.6.6<br>
> and the user already installed any eventually available newer <br>
> version (like 2.6.7).</font></tt>
<br>
<br><tt><font size=2>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".</font></tt>
<br><tt><font size=2>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. </font></tt>
<br><tt><font size=2><br>
> As a conclusion this checkpolicy=always attribute is very likely to
<br>
> lead to many support requests and problems since most WPKG users are
not defining such<br>
> detailed checks but rather relying on simple uninstall entry exist
checks. In<br>
> such cases upgrades would not be performed at all if <br>
> checkpolicy=always is used.</font></tt>
<br>
<br><tt><font size=2>True. If committed (not probable I guess), the documentation
should clearly mention that you need _detailed_ check policies.</font></tt>
<br><tt><font size=2><br>
> On the other hand there is a very simple solution for the problem
outlined by<br>
> Marc Hennes. Just define the exit code indicating that a newer version
is<br>
> already installed as a successful exit code in the package definition.
So WPKG<br>
> will know the update was successful, then WPKG will also run the checks
to<br>
> verify the system state and then (if checks succeed) just accept thepackage
to<br>
> be installed properly.</font></tt>
<br>
<br><tt><font size=2>Hmm... This is even harder to test than detailed check
policies... I kinda like this more:</font></tt>
<br><tt><font size=2><br>
> Another very simple solution is to call a simple cmd script by WPKG
<br>
> (instead of the installer directly) where the cmd script performs
some <br>
> application-specific checks and either just exits with a defined code
(e.g. 0: installed<br>
> successfully, 1: installation failed, 2: already installed ...) <br>
> depending on the action it really performed.</font></tt>
<br>
<br><tt><font size=2>... 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>.</font></tt>
<br><tt><font size=2><br>
> I am just not a friend of introducing thousands of switches which
makes WPKG<br>
> complex, difficult to test and understand for the user. For exampel
the<br>
> checkpolicy=always switch would require quite a lot of new test <br>
> cases to verify<br>
> its function with packages with "generic" checks (e.g. uninstall
entry with no<br>
> version number), with "detailed" checks (e.g. uninstall
check with version<br>
> number), where user already installed a newer version, where user
did not<br>
> install a newer version etc.</font></tt>
<br>
<br><tt><font size=2>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.</font></tt>
<br><tt><font size=2><br>
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?"</font></tt>
<br>
<br><tt><font size=2>> In addition there is an extremely small amount
of software packages where this<br>
> specific switch makes any sense and the potential that WPKG users
will not<br>
> understand it is quite high. So users will impose support effort by
asking for<br>
> its functionality or even worse use it wrongly and end up with non-updated<br>
> systems (see example above).</font></tt>
<br>
<br><tt><font size=2>I don't know if you're right here. I guess with proper
documentation, this switch might be pretty useful. </font></tt>
<br><tt><font size=2>And there's other things in WPKG that are more confusing
(like reboot=true having different meanings in <package> and <exit>)</font></tt>
<br>
<br><tt><font size=2>In a controlled environment (enduser doesn't install
software), you won't need that - but at least my environment is not that
controlled.</font></tt>
<br><tt><font size=2><br>
> Moreover most installers behave nicely when an installation of an
already<br>
> installed version is performed. They just abort installation and <br>
> report success or a specific exit code.</font></tt>
<br>
<br><tt><font size=2>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.</font></tt>
<br>
<br><tt><font size=2>I'd rather write a sophisticated uninstall check than
testing all installers how they behave. Every installer behaves differently
- but <check> is pretty predictable.</font></tt>
<br><tt><font size=2><br>
[...]<br>
> For more advanced users a simple cmd script which performs pre-installation<br>
> checks might be used. Usually simple scripts like this should do the
trick:<br>
> <br>
> install-software.cmd:<br>
> ----<br>
> @echo off<br>
> <br>
> reg query HKLM\.... | findstr "<version>"<br>
> :: already installed<br>
> if %ERRORLEVEL% EQU 0 exit 0<br>
> :: version mismatch<br>
> start /wait "installer" <installer> <switches><br>
> ----</font></tt>
<br>
<br><tt><font size=2>Hmm... that makes me missing out on the very excellent
checks WPKG already has.</font></tt>
<br>
<br><tt><font size=2>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:</font></tt>
<br>
<br><tt><font size=2>
<check type="logical" condition="or"></font></tt>
<br><tt><font size=2>
<check type="uninstall"
condition="versiongreaterorequal" path="Adobe Flash Player
10 ActiveX" value="10.0.45.2" /></font></tt>
<br><tt><font size=2>
<check type="logical"
condition="not"></font></tt>
<br><tt><font size=2>
<check type="uninstall" condition="exists"
path="Adobe Flash Player 10 ActiveX" /></font></tt>
<br><tt><font size=2>
</check></font></tt>
<br><tt><font size=2>
</check></font></tt>
<br>
<br><tt><font size=2>
<download url="http://<wpkg-server>/Adobe
Flash/install_flash_player_ax-10.0.45.2.exe" target="wpkg-installers\install_flash_player_ax.exe"
/></font></tt>
<br><tt><font size=2>
<install cmd='"%TEMP%\wpkg-installers\install_flash_player_ax.exe"
/S' /></font></tt>
<br><tt><font size=2>
<upgrade cmd='"%TEMP%\wpkg-installers\install_flash_player_ax.exe"
/S' /></font></tt>
<br>
<br><tt><font size=2>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.</font></tt>
<br>
<br><tt><font size=2>If you don't mind, I'll try to keep the patch in the
bugzilla bug updated with new wpkg revisions.</font></tt>
<br>
<br><tt><font size=2>Best Regards</font></tt>
<br><tt><font size=2> Heiko Helmle</font></tt>