http://bugzilla.wpkg.org/show_bug.cgi?id=79 Rainer Meier <skybeam at users.sourceforge.net> changed: What |Removed |Added Attachment #64 is|0 |1 obsolete| | --- Comment #42 from Rainer Meier <skybeam at users.sourceforge.net> 2007-11-15 21:55:16 --- Created an attachment (id=65) --> (http://bugzilla.wpkg.org/attachment.cgi?id=65) Full package, fixed log level, added reboot=delay feature, added profile-based log level, upgrade-before-remove feature Hi all, So here I have another modified/fixed version. Many thanks to Falko Trojahn for very detailed issue-reporting and verification of practical use. Change log: * 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"> * ... * </profile> * 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 to config.xml. I re-structured and commented config.xml. Some users might not even have to uncomment one of the parameters. -- Configure bugmail: http://bugzilla.wpkg.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug. wpkg-users mailing list wpkg-users at lists.wpkg.org http://lists.wpkg.org/mailman/listinfo/wpkg-users |