[wpkg-users] [Bug 122] New type of execute=""

[bugzilla-daemon at bugzilla.wpkg.org]

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.