Triggers

Status

Details

Triggers are a way of deferring common operations until they are needed, and performing them only once instead of once for every package that requires it. The best examples are running ldconfig or scrollkeeper-update in your package's postinst script.

Packages provide trigger scripts identified by a unique name, probably including the package name.

Other packages that depend on them can then request in their action script that the trigger be run at some point during the dpkg run. Triggers should be used where the exact time of invocation isn't important, and that the commands the trigger run don't require any arguments to work. 

dpkg-trigger ldconfig

Packages can also require that a certain trigger have been run now if any packages have requested it so far in the dpkg run. Otherwise all requested triggers are run before dpkg terminates. 

dpkg-trigger --now ldconfig

The intent is to vastly decrease the number of times common operations need to be performed, theoretically to one done at the end of the run.

Alternative Design

This is an alternative design by Ian Jackson and Wichert Akkerman.

Instead of using a seperate program like this, instead all packages may include a trigger script (just like they can include postinst, etc.) and give the circumstances for which this should be run.

libc6 (which is the package ldconfig is contained in) could ask for its trigger to be run whenever a file is installed into /lib, /usr/lib, etc. emacs when files are installed in its lisp directories, scrollkeeper when new files are added, etc.

When the event is noticed, the package status would be changed from installed to needs-trigger -- which would be picked up by dpkg. The resolution is to run the trigger and restore the package's state to installed again.

Use Cases

dpkg: Triggers (last edited 2005-10-17 13:03:11 by JeffWaugh)