Re: Draft spec for new dpkg "triggers" feature
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
Reply to: