[wpkg-users] Package upgrade and checks

[Rainer Meier]

Hi both,

On 22.04.2010 09:55, heiko.helmle at horiba.com wrote:
> This is correct and documented (but i admit a little unexpected) behaviour.
> 
> I wrote a patch some time ago that makes this configurable - but since
> there was no reaction, I assumed everybody was okay with the original
> behaviour.
> 
> anyways, here's the bug: http://bugzilla.wpkg.org/show_bug.cgi?id=180
> 
> once you applied the patch to wpkg.js you can use "checkpolicy=always"
> in the package definition to force checks on update.

In case of upgrades it's true that WPKG will in any case run the upgrade
commands. In most cases this is even required since a lot of packages would
never upgrade otherwise.
A lot of packages just have checks like "uninstall entry 'xy' exists" and if
WPKG would execute the checks it would assume the new version to be installed
already and will never perform an upgrade.
Sure one could say that checks should check for a specific version but then
these checks are likely to fail already when the user performs a manual upgrade.


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.

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.

So now you might argue that you can insert a check for a file version. So add a
check for file version 2.6.5.
Unfortunately this will prevent users to install new versions completely since
WPKG will detect on each run that version 2.6.5 is not installed properly and
re-install it. In some cases (your MSI example) this might fail since the
installer claims a newer version is already installed. In some (most) cases it
will just lead to a downgrade of Pidgin to version 2.6.5 on each WPKG run.



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



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.


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 the package to
be installed properly.
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.

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.

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).
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.
In case of upgrade it will always be a problem if you let users do their own
software updates. The reason is that you will not have any clue any more which
version is installed at the point where WPKG performs the upgrade to a new
official release by the system administrator. In most cases it will work
properly because most installers just overwrite what is installed on the system
and will therefore just upgrade/downgrade now matter what the user installed.
Unfortunately also here it might fail for some specific installers and the
upgrade procedure might be different depending on the version currently
installed. As you don't know the version currently installed it is very
difficult to write an install script which covers all cases.



So to summarize: My recommendation is to let WPKG perform the upgrade as it is
doing now. Most installers will detect if this version is already installed and
abort. Then just tell WPKG that this specific exit code indicates success.

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

As I said usually it's not a problem running the installer in any case and just
let WPKG act on its exit code so such a script is only required if you like/need
to prevent WPKG from running the installer.


br,
Rainer