On (30/01/07 17:08), Ian Jackson wrote: > For some time the idea of having some kind of event queue notification > mechanism in dpkg has been floating about. For example, it would be > used to avoid running scrollkeeper-update dozens of times during an > upgrade and could simplify the emacs addon registration. Wichert and > I even had a good design conversation in a taxi some years ago but we > failed to make proper notes and write it up. > > I hope to be able to implement such a feature at some point in the > nearish future. To this end I've written a draft specification which > you can find below. If you're interested, please read it and comment.
Thanks for the very detailed specification. > activate <trigger-name> > > Arranges that any change of the package's state will activate the > specified trigger. The trigger will be activated just before the > package state changes. > Could you please clarify this a little for me. The activate is for the non-file triggers correct? When you say "any change of the package's state" does this really mean any change, as in will it trigger multiple times on package install, for purged -> half-installed -> installed? If so does this actually cause the trigger to run more than once, or do triggers by their nature only run once in this case even though they are activated many times. I can see why it might be useful for dealing with failed installations to make sure the triggers are run correctly. However if they are run multiple times then there may be a desire for more fine grained control. Another example use case for you. The Xfce desktop environment is quite modular and has an mcs-manager which is a central configuration manager. Each component that has a desire to make something configurable using this interface provides a plugin to it, which is a shared library that is opened at runtime (or something approximating this). When a new plugin is installed then the manager needs to be refreshed so that it can see it without restarting X. This is done by executing xfce-mcs-manager --refresh or something. Currently all of the plugins do this in their postinst. The refresh option has had problems before so the developer has now made it re-exec the manager fully, which takes a little time. The worst part is that the gtk theme is lost during this operation causing "flashing" on the screen. One of the maintainers has been thinking about ways to only do this once per upgrade to minimise it, but never really came up with a good solution, and even thought about just disabling it and leving the plugins messed up until an X restart was done. It seems like triggers would be perfect for this, and would be appreciated by me at least to avoid this issue, and others. This could be done (or at least could be made to) with a file trigger I believe, but for the sake of argument say it isn't. The refresh only needs to be done if one plugin makes it to the installed stage, anything else is a waste, but not an actual problem. Thanks again, James [Please Cc: me on any replies] -- James Westby -- GPG Key ID: B577FE13 -- http://jameswestby.net/ seccure key - (3+)k7|M*edCX/.A:n*N!>|&7U.L#9E)Tu)T0>AM - secp256r1/nistp256 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
