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.html>
|
|