Hi Simon, simplesi wrote: > Just a simple question as I've never used checks before :) Nice to see that you're trying to enhance your packages now :-) > Are checks just used for the install command? Checks are used to prove that a package is correctly installed. Preferably checks are fine grained enough to detect that a specific version of the software is installed. After each upgrade/install/downgrade/remove the checks are executed and if the result is "true" WPKG knows the install/upgrade/downgrade/remove has been successful. So if you just check for existence of an uninstall string like "Pidgin" you can be sure that Pidgin is installed but you're actually not verifying the version. Usually this is just fine since WPKG is quite reliable in executing upgrades. If you want to be sure at any case that the binaries are in place you might add a check for file version as well. For some software the uninstall entry contains the version too - for example "Mozilla Firefox 3.5.3". As an example - you might have a Firefox package defining an uninstall check for "Mozilla Firefox 3.5.2" so WPKG will do the following: - On the first run it checks if this entry already exists. If yes, then no installation is done and WPKG assumes the software is installed already. - On each subsequent run WPKG verifies that the "Mozilla Firefox 3.5.2" entry is still in the uninstall program list. If it is not, then the install commands are executed again. This makes WPKG assure that "Mozilla Firefox 3.5.2" is really installed. Let's assume you're going to upgrade to Firefox 3.5.3 now. So you have to do the following: - Update the check to check for "Mozilla Firefox 3.5.3" uninstall entry - Update the install commands to point to the 3.5.3 installer - Update the upgrade commands to point to the 3.5.3 installer - Increase package revision So on next WPKG run WPKG will detect that the package revision has been increased and will run the upgrade commands. After this the checks are executed to see if "Mozilla Firefox 3.5.3" exists in the uninstall entries list. If not it reports an error (failed check after upgrade). It will re-try to install/upgrade at any run until checks are met. If you remove a package then WPKG runs the remove commands. After running them WPKG runs the checks to verify that they do not yield true any more (package removed). So to repeat. The checks have ALWAYS to verify that the version you intend to install is correctly applied to the system. So it actually allows WPKG to verify that your commands did their job correctly. > Are they ignored when a package revision is incremented and the upgrade > command is executed? No. See above. After upgrade the checks are re-run. This allows you to verify that your commands have been successful. > Or can you have separate check conditions for an upgrade? No need for that. A package's purpose is to bring the system to a defined state. Either by installing (if not installed before) or by upgrading (if software is installed already but outdated). The checks after install/upgrade should be the same if the software is installed successful. If upgrades would have to verify different things than a plain installation you might add multiple checks for both variants using a logical OR. For example if you have - Application Version X.0 and you get a new version where the upgrade leaves an uninstall entry like - Application Version X.1 Update and a fresh installation just leaves - Application Version X.1 then you could check that either "Application Version X.1 Update" OR "Application Version X.1" is installed properly (both meaning the same software revision). Actually I've never discovered such a thing. In the example above you could even use a regular expression like "^Application Version X\.1.*" to match both entries with one check - so if either of them is present you know that version X.1 is installed. br, Rainer |