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 |