So here I have another modified/fixed version. Many thanks to Falko Trojahn for
very detailed issue-reporting and verification of practical use.
* FIX: Fixed always printing debug to event log (even if /debug was disabled).
* NEW: The reboot=true attribute on an exit code forces an immediate reboot.
* Unfortunately all following commands are skipped then. Sometimes
* (maybe even more often) you might like to just set the package reboot
* flag depending on a command exit code. I introduced the support of
* reboot='delay' within the command nodes. This allows to schedule a
* reboot instead of immediately executing it. The effect is the same
* as setting reboot='true' on package level (reboot after executing
* all comands. However it allows you to leave reboot='false' on package
* level and schedule a reboot based on command exit codes.
* NEW: Added support for profile-based log level. You might use a profile node
* as follows:
* <profile id="profileID" logLevel="0xFF">
* If not specified it keeps the default log level. So final evaluation
* priority is as follows:
* - config.xml
* - command line parameter (/logLevel:<#>)
* - profile-specific logLevel
* MOD: Upgrading to the latest package version before removing a package
* (if package is still available on server). This allows administrators
* to fix broken uninstall commands by supplying a new package with fixed
* commands. WPKG will now first do the upgrade and then execute the
* uninstall commands.
Especially the reboot=delay feature might be very helpful for several packages.
Sometimes you just like like to schedule a reboot after installing all the
commands instead of forcing an immediate reboot. Some might say that for such
purpose you can set the package reboot flag. However this will initiate a
reboot after installation in _any_ case. The reboot=delay flag on an exit code
definition allows to specify reboot=false on package level and change this
decision based on exit codes.
Falko reported that administrators migh like to use a different log level for
nodes belonging to a certain (test)-profile. That's why I added the possibility
to specify the logLevel attribute within the profile node.
The upgrade-before-remove modification will make sure that in case a package is
removed from the profile it is first upgraded to the latest version before
removing it. While this might sound like useless overhead it allows system
administrators to provide a fixed version of the package where the uninstall
procedure works as expected. In case clients operate on a specific version of
the package where the uninstall command might fail there was no possibility for
administrators to fix that (except manually upgrading to a new version first).
Unfortunately administrators might have no control how long it takes until all
clients have applied the new package.
Using this modification it allows administrators to provide a fixed package on
the server while directly removing it from the profile. All clients will then
first upgrade to the latest package (which even does not have to install a new
version of the application itself but just contain uninstall strings) and then
remove it correctly in one shot.
Here I would like to point out another difference to previous WPKG versions. In
case a package is removed from the profile AND from the package database there
is no way for system administrators to fix eventually broken uninstall strings.
In old versions it was then continuously printing an error that the package is
a zombie (without even trying an uninstall).
My redesign will try one single uninstall. If it fails it will remove the local
package node from wpkg.xml anyway. Remember - it will do that only if the
package does not exist within the server package database AND not referenced
within the profile. If you like to disable this use the /noforcedremove switch.
Additionally Falko provided a french translation (to be verified) which I added
I re-structured and commented config.xml. Some users might not even have to
uncomment one of the parameters.