Re: Draft spec for new dpkg "triggers" feature
Ian Jackson <email@example.com> writes:
> A file trigger is guaranteed to be activated before the file in
> question is modified by dpkg; on the other hand, a file trigger might
> be activated even though no file was actually modified.
How should that work for the fonts, info pages, manpages, ....
In those cases it would be nice to have a trigger for a directory but
only have it called after the fact, when the new files are in place
and the old files already removed.
> When triggers are available, this will work as follows:
> * gnome-foobar will ship its `omf' file in /usr/share/omf as
> normal, but will not contain any special machinery to invoke
> * scrollkeeper will in its triggers control file say:
> interest /usr/share/omf
> and in its postinst say:
> scrollkeeper-update -q
> dpkg will arrange that this is run once at the end of each run
> where any documentation was updated.
Isn't that a file trigger and would be called _before_ the file is
modified? The example is actualy the wanted behaviour while the specs
above seem to deviate.