http://bugzilla.wpkg.org/show_bug.cgi?id=122 Rainer Meier <r.meier at wpkg.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |r.meier at wpkg.org Status|NEW |RESOLVED Resolution| |WONTFIX --- Comment #1 from Rainer Meier <r.meier at wpkg.org> 2009-04-11 20:22:11 --- Actually I think this could be implemented using a post-WPKG execution task. Probably also with a wrapper running wpkg.js and monitoring its output (using /sendStatus would be a good idea) to know if WPKG did a change to the system. I don't see a possibility to include an execute="changed" attribute in the current WPKG architecture because also the priorities would require these packages to be executed at the end of WPKG processing. So I really suggest solving the problem differently. In your case it might be helpful to look at the cleanup script as well. I don't think what you described should take longer than 3 seconds to complete unless there is something seriously wrong on the system or with the algorithm of the tool. In addition I am doing start-menu cleanup as well but slightly differently. I am attaching a post-install script to the package install command which cleans up the program entries of the program I just installed. This keeps my start menu (and also the Desktop) clean for each WPKG installation If you want to handle non-wpkg start menu changes too then your execute="changed" approach does also not offer a great improvement because then the start menu will be "messy" until WPKG installs the next package/update. But if you want to attach the execution of this cleanup script to a package operation why not directly attaching it to the package definition? It is easy to specify the cleanup action as a post-installation command within the package definition. So it will be executed after package install/upgrade. The only difference is that you directly add it to the commands of _each_ package - which is really not a big effort to add. -- Configure bugmail: http://bugzilla.wpkg.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug. |