Hi all, I've just finished working on some bugs reported on last WPKG pre-release. It also contains some new features. You can download the full package at: <http://wpkg.org/files/beta/WPKG-1.1.3-RC11.zip> (it's not uploaded yet, but for sure Tomasz will do it soon) Of course you can also just get the latest wpkg.js from SVN: <http://wpkg.svn.sourceforge.net/viewvc/wpkg/wpkg/stable/1.1/> Recent changes: Changes 2011-07-03, v1.1.3-RC11 by Rainer Meier <r.meier (at) wpkg.org> NEW: Allow to specify multiple packages to be installed/removed/upgraded on command-line. Just specify a comma-separated list of packages: cscript wpkg.js /install:package1,package2,... Implements bugzilla 204. Thanks to Michael Croes for reporting. NEW: Allowing use of environment variables in file size checks: <check type="file" condition="sizeequals" path="%ProgramFiles%\%PKG_DST%" value="%PKG_SIZE%" /> Fixes bug report 212. Thanks to Stefan Pendl for reporting. Changes 2011-07-03, v1.1.3-RC10 by Rainer Meier <r.meier (at) wpkg.org> FIX: Fixed bug when using /debug switch (or implicit enable of /debug by using /dryrun switch or config.xml flag). The issue was introduced with new host attribute matching and advanced host identification in debug messages. Fixes bug 210. Thanks to Stefan Pendl for reporting. NEW: Extended host attribute verification is now allowed to be used in package commands too. Commands which specify additional host attributes are ignored if one of the extended attributes do not match the executing host. e.g. <install cmd="command" ... os="windows 7" ipaddresses="^192\.168\.1\..*" domainname="^domain$" groups="^group.*$" architecture="x86" /> Note: All special parameters (os, ipaddresses, domainname, groups) are specified as regular expressions. Especially keep this in mind when specifying IP-addresses or any parameter including periods (.). As a period in regular expression means "any character". So keep in mind to escape special regular expression characters. As a result you can use extended host check attributes in the following locations: - host matching <host name="hostname" priofile-id="profile" ... architecture="x64" ... /> - profile packages <package package-id="package" ... architecture="x64" ... /> - package commands <install cmd="command-line" ... architecture="x64" ... /> <remove cmd="command-line" ... architecture="x64" ... /> <upgrade cmd="command-line" ... architecture="x64" ... /> <downgrade cmd="command-line" ... architecture="x64" ... /> NEW: Added attributes to package nodes which allow to control whether checks shall be execute before install/upgrade/downgrade/remove. By default WPKG only executes checks before first installation in order to prevent re- installing a package which is already installed. Using the new attributes it allows you to enable these checks before upgrade/downgrade/remove too. For example if you use precheck-upgrade="always" and upgrade a package, then WPKG will first run the checks and if they succeed WPKG will skip the execution of upgrade commands and just assume this version is already installed. Be careful when using these attributes as it might lead WPKG to skip upgrades/downgrades if your checks are not sufficiently specific. For example if your check just checks for an uninstall entry existence which is true for the old and the new version, then precheck-upgrade="always" would make WPKG believe that the upgrade has been performed already as the uninstall check from the updated package succeeds. So make sure to include some checks which are true for the new package, but not for the old one. Here is some documentation on the attributes (all of them are optional): <package ... precheck-install="never|always" precheck-remove="never|always" precheck-upgrade="never|always" precheck-downgrade="never|always" /> Notes on "precheck-install": Defines how package checks are used during package installation. Currently supported values: "always" (default): When a package is new to the host then first the checks are run in order to verify whether the package is already installed. If the checks succeed then it is assumed that no further installation is needed. The package is silently added to the host without executing any commands. "never": When a package is new to the host then the install commands are run in any case (without doing checks first). Note: Checks will still be done after package installation to verify whether installation was successful. Notes on "precheck-remove": Defines how package checks are used during package removal. Currently supported values: "always": When a package is removed from a host then the checks will be executed before removal is processes. If the checks fail this potentially means that the package has been removed already. In such case the package remove commands will be skipped. "never" (default): When a package is about to be removed from the host then WPKG will execute the remove commands in any case without executing the checks first. Note: Checks will still be done after package removal to verify whether the removal was successful. Notes on "precheck-upgrade": Defines how package checks are used during package upgrade. Currently supported values: "always": When a package is upgraded the checks specified will be be executed before the upgrade takes place. If checks succeed, then the upgrade will not be performed (WPKG just assumes that the new version is already applied correctly. Please note that your checks shall verify a specific software version and not just a generic check which is true for all versions. If your checks are true for the old version too then WPKG would never perform the upgrade in this mode. "never" (default): When a package is about to be upgraded then WPKG will execute the upgrade commands in any case without executing the checks first. This is the recommended behavior. Note: Checks will still be done after package upgrade to verify whether the upgrade was successful. Notes on "precheck-downgrade": Defines how package checks are used during package downgrade. Currently supported values: "always": When a package is downgraded the checks specified will be be executed before the downgrade takes place. If checks succeed, then the downgrade will not be performed (WPKG just assumes that the old version is already applied correctly. Please note that your checks shall verify a specific software version and not just a generic check which is true for all versions. If your checks are true for the new/current version too then WPKG would never perform the downgrade in this mode. "never" (default): When a package is about to be downgraded then WPKG will execute the downgrade commands in any case without executing the checks first. This is the recommended behavior. Note: Checks will still be done after package downgrade to verify whether the downgrade was successful. This implements a change request reported in Bugzilla report 180. FIX: Fixed using of lcid="<lcid>" attribute within variable definition in packages. It was documented in packages.xsd but not implemented in wpkg.js. Fixes bug 206. Thanks to Stefan Pendl. FIX: Fixed cosmetic issue in host matching output. Fixes bug 211. Thanks to Stefan Pendl for reporting. ################################################################################## Full list of changes since last release ################################################################################## Change notes ============ WPKG Version: 1.1.3-RC11 Author: : Rainer Meier <skybeam (at) users.sourceforge.net> Date : 2011-07-03 Status : release pending Changes/fixes visible to the user: Summary: - Fixed IP-address match in case 3 "." are used in host matching string. - Fixed package removal procedure exception in case of /noremove flag is used. - Fixed removal of settings entry in case of /noremove and no package checks. - Allow folders to be checked with file checks. - Allows recursive search for uninstall entries in registry - Enhance wrapper.js to use sysnative cmd.exe. - Disabled recursive registry uninstall checking again due to slow execution. - Closing STDIN when executing commands. - Extended host matching for OS, IP, domain and groups. - Fix for crash if interface has no IP bound to it. - Fix for registry exist checks not returning true. - Fix for execute test writes null values to the logs. - Fix included estetic break. - Extended host attribute match for host architecture. - Extended host attribute match for environment variables. - Support for host attribute matches in <package/> definitions within profiles. - Small fixes and optimizations. - New /noDownload switch. - Fixed debug mode (broken since introduced advanced host checks). - Added extended host attribute match for package commands. - Added package pre-check attributes to package nodes. - Fixed ignore of lcid in package variables. - Cosmetic fix in extended host matching debug output. - Allow multiple packages to be installed/removed/upgraded in one-shot. - Allow variable expansion in file size checks. NEW: Updated IP matching algorithm to prevent accidental matching if regexp or host name is used which uses exactly 3 "." within the string. Thanks to Stefan Pendl for reporting. FIX: Fixed package removal procedure in case /noremove flag is set. WPKG would have failed (exception thrown) in case /notemove was used and a package is detected NOT to be installed. FIX: In case /noremove is used and the package does not define any checks WPKG is unable to detect if the package is still installed or not. Previously WPKG was assuming that the package is not installed and removed it from the local settings file. This has been changed. The package will now only be removed from the settings file if it defines some checks which allow WPKG to clearly detect that the package is not installed on the system. So if the package does not define any checks WPKG assumes it's still installed on the systme and does not remove its entry from the local settings file (wpkg.xml). FIX: Updated "file" type checks to match folders too. Now a check of type file for condition exist yields true for a patch referring either a file or a folder. Thanks to Joe for reporting. NEW: WPKG now allows uninstall entries to be defined in sub-nodes of the uninstall registry key. I was unable to verify that Windows supports such entries but as reported RationalPlan Viewer seems to add such a sub-node: Uninstall\RationalPlan\Viewer. There might be other programs doing the same. During tests Windows XP and Windows 7 were ignoring such entries but now WPKG supports these entries now. (NOTE: Disabled again, read below) NEW: Enhanced wrapper.js to use sysnative directory. The sysnative directory allows 32-bit programs to access the 64-bit binaries within %SystemRoot%\system32\. This way it is not necessary any more to copy the 64-bit version of cmd.exe to the 64-bit\ sub-folder since the wrapper can launch the locally available 64-bit cmd.exe. MOD: Disabled recursive uninstall checks again. Reading registry keys recursively is very slow with WSH and since there are typically many sub-keys within the uninstall locations this causes a very long delay each time an uninstall check is used. It's recommended to use a registry value check instead of an uninstall check in order to check for the status of an application which puts its uninstall entry within a sub-key of the uninstall keys in the registry. MOD: WPKG now closes STDIN when executing external commands. Some applications seem to wait for STDIN to be closed before they exit. Microsoft PowerShell seems to be one of the affected applications. Since closing STDIN should not have negative effects (WPKG will not write to STDIN) it's supposed to be safe to close it. Thanks to Stéphane Bilqué for reporting. NEW: Many extensions in host matching. Now a host entry in hosts.xml is allowed to include the following attributes: <host name='host-x' profile-id='profile-reference' os="windows 7" ipaddresses="^192\.168\.1\..*" domainname="^domain$" groups="^group.*$" /> Note: All special parameters (os, ipaddresses, domainname, groups) are specified as regular expressions. Especially keep this in mind when specifying IP-addresses or any parameter including periods (.). As a period in regular expression means "any character". So keep in mind to escape special regular expression characters. Many thanks to Daniel Dehennin for continued support of this changes. It just almost took as long as finishing DNF to include it. *sigh* FIX: Included fix for bug 196 which could make WPKG crash in case no IP address is assigned to a network card. Thanks to Daniel Dehennin again. FIX: Included fix for bug 199 where registry exist checks did not return true. Thanks to Daniel Dehennin again. FIX: Included fix for bug 200 where execute test fallback to 'exitcodeequalto' in 'execute' tests writes null values to the logs. Thanks to Daniel Dehennin again. FIX: Included esthetic break statement in check condition for uninstall checks. Thanks to Daniel Dehennin again. NEW: Extended host attribute match now allows to match architecture using architecture="<arc>" attribute. The following architectures are currently supported: x86 32-bit operating system x64 64-bit operating system Note: You will have to match x86 also if you run Windows 32-bit on AMD64/EMT64/x64 hardware. NEW: Extended host attribute match allows to match environment variables using environment="variable1=^regexp$|variable2=regexp..." attribute. Please note that regular expressions are matched case-insensitive and multiple variables have to be separated by the pipe ('|') character. Please also note that in case you use WPKG-client the system-user environment might differ from the environment you see when opening a command prompt and typing 'set'. Some variables might be missing and others might have different content. So use with caution. NEW: Extended use of host matches. Now WPKG supports host matches from previous update not only in <host /> definitions but also in <package /> definitions used within <profile /> nodes. This allows profiles where certain packages are applied only if specific host-conditions match. For example: <profile id='default'> <package package-id='AdobeReader' os="windows 7" architecture="x64" /> <package package-id='audacity' /> <package package-id='pidgin' os="windows 7" /> <package package-id='firefox' environment="NUMBER_OF_PROCESSORS=^4$" /> </profile> This example would install "AdobeReader" only on systems with Windows 7 64-bit edition running while "pidgin" is installed on all Windows 7 hosts regardless of the architecture. The "firefox" package would be installed only if WPKG runs within an environment which defines the NUMBER_OF_PROCESSORS environment variable to the value "4". The "audacity" packages would be installed on any host which gets the 'default' profile assigned. MOD: Some smaller fixes and optimizations. NEW: Added /noDownload option (and noDownload property in config.xml) to disable downloads globally. When the switch is used then WPKG just ignores any download specification. Use with caution as your install/upgrade/... commands might depend on downloaded files. So make sure that you fetch the files which would be downloaded prior to WPKG execution. Thanks to Marco Gaiarin. FIX: Fixed using of lcid="<lcid>" attribute within variable definition in packages. It was documented in packages.xsd but not implemented in wpkg.js. Fixes bug 206. Thanks to Stefan Pendl. FIX: Fixed bug when using /debug switch (or implicit enable of /debug by using /dryrun switch or config.xml flag). The issue was introduced with new host attribute matching and advanced host identification in debug messages. Fixes bug 210. Thanks to Stefan Pendl for reporting. NEW: Extended host attribute verification is now allowed to be used in package commands too. Commands which specify additional host attributes are ignored if one of the extended attributes do not match the executing host. e.g. <install cmd="command" ... os="windows 7" ipaddresses="^192\.168\.1\..*" domainname="^domain$" groups="^group.*$" architecture="x86" /> Note: All special parameters (os, ipaddresses, domainname, groups) are specified as regular expressions. Especially keep this in mind when specifying IP-addresses or any parameter including periods (.). As a period in regular expression means "any character". So keep in mind to escape special regular expression characters. As a result you can use extended host check attributes in the following locations: - host matching <host name="hostname" priofile-id="profile" ... architecture="x64" ... /> - profile packages <package package-id="package" ... architecture="x64" ... /> - package commands <install cmd="command-line" ... architecture="x64" ... /> <remove cmd="command-line" ... architecture="x64" ... /> <upgrade cmd="command-line" ... architecture="x64" ... /> <downgrade cmd="command-line" ... architecture="x64" ... /> NEW: Added attributes to package nodes which allow to control whether checks shall be execute before install/upgrade/downgrade/remove. By default WPKG only executes checks before first installation in order to prevent re- installing a package which is already installed. Using the new attributes it allows you to enable these checks before upgrade/downgrade/remove too. For example if you use precheck-upgrade="always" and upgrade a package, then WPKG will first run the checks and if they succeed WPKG will skip the execution of upgrade commands and just assume this version is already installed. Be careful when using these attributes as it might lead WPKG to skip upgrades/downgrades if your checks are not sufficiently specific. For example if your check just checks for an uninstall entry existence which is true for the old and the new version, then precheck-upgrade="always" would make WPKG believe that the upgrade has been performed already as the uninstall check from the updated package succeeds. So make sure to include some checks which are true for the new package, but not for the old one. Here is some documentation on the attributes (all of them are optional): <package ... precheck-install="never|always" precheck-remove="never|always" precheck-upgrade="never|always" precheck-downgrade="never|always" /> Notes on "precheck-install": Defines how package checks are used during package installation. Currently supported values: "always" (default): When a package is new to the host then first the checks are run in order to verify whether the package is already installed. If the checks succeed then it is assumed that no further installation is needed. The package is silently added to the host without executing any commands. "never": When a package is new to the host then the install commands are run in any case (without doing checks first). Note: Checks will still be done after package installation to verify whether installation was successful. Notes on "precheck-remove": Defines how package checks are used during package removal. Currently supported values: "always": When a package is removed from a host then the checks will be executed before removal is processes. If the checks fail this potentially means that the package has been removed already. In such case the package remove commands will be skipped. "never" (default): When a package is about to be removed from the host then WPKG will execute the remove commands in any case without executing the checks first. Note: Checks will still be done after package removal to verify whether the removal was successful. Notes on "precheck-upgrade": Defines how package checks are used during package upgrade. Currently supported values: "always": When a package is upgraded the checks specified will be be executed before the upgrade takes place. If checks succeed, then the upgrade will not be performed (WPKG just assumes that the new version is already applied correctly. Please note that your checks shall verify a specific software version and not just a generic check which is true for all versions. If your checks are true for the old version too then WPKG would never perform the upgrade in this mode. "never" (default): When a package is about to be upgraded then WPKG will execute the upgrade commands in any case without executing the checks first. This is the recommended behavior. Note: Checks will still be done after package upgrade to verify whether the upgrade was successful. Notes on "precheck-downgrade": Defines how package checks are used during package downgrade. Currently supported values: "always": When a package is downgraded the checks specified will be be executed before the downgrade takes place. If checks succeed, then the downgrade will not be performed (WPKG just assumes that the old version is already applied correctly. Please note that your checks shall verify a specific software version and not just a generic check which is true for all versions. If your checks are true for the new/current version too then WPKG would never perform the downgrade in this mode. "never" (default): When a package is about to be downgraded then WPKG will execute the downgrade commands in any case without executing the checks first. This is the recommended behavior. Note: Checks will still be done after package downgrade to verify whether the downgrade was successful. This implements a change request reported in Bugzilla report 180. FIX: Fixed using of lcid="<lcid>" attribute within variable definition in packages. It was documented in packages.xsd but not implemented in wpkg.js. Fixes bug 206. Thanks to Stefan Pendl. FIX: Fixed cosmetic issue in host matching output. Fixes bug 211. Thanks to Stefan Pendl for reporting. NEW: Allow to specify multiple packages to be installed/removed/upgraded on command-line. Just specify a comma-separated list of packages: cscript wpkg.js /install:package1,package2,... Implements bugzilla 204. Thanks to Michael Croes for reporting. NEW: Allowing use of environment variables in file size checks: <check type="file" condition="sizeequals" path="%ProgramFiles%\%PKG_DST%" value="%PKG_SIZE%" /> Fixes bug report 212. Thanks to Stefan Pendl for reporting. br, Rainer |