So I've modified update-menus as the triggers docs suggest, so that
when it's run by a postinst and --real is not passed, it runs
dpkg-trigger /usr/share/menu and then exits. If --real is passed, it
does a menu update (in the foreground, no more forking to background).
I made menu declare interest in /usr/share/menu, and I added a triggered
action to its postinst, that calls update-menus --real.
Here's what I'm seeing with the new dpkg when I install packages that
contain menu files and that also run update-menus in their postinsts:
Unpacking xaos (from .../archives/xaos_3.3-1_i386.deb) ...
Selecting previously deselected package xemeraldia.
Unpacking xemeraldia (from .../xemeraldia_0.4.1-4_i386.deb) ...
Processing triggers for menu ...
Setting up xaos (3.3-1) ...
Setting up xemeraldia (0.4.1-4) ...
Processing triggers for menu ...
Note the dual trigger run. The first time occurs after the packages are
unpacked, when the /usr/share/menu files are updated. The second time
occurs after the postinsts run, since they trigger again by running
update-menus.
Of course once all packages are updated to drop the update-menus calls,
the trigger will only run once per dpkg invocation of a menu-providing
package. So this is temporary. It's also probably fine to run
update-menus trice for a while. Just wanted to make sure this is
as-indended, since I don't remember realizing this would happen when I
read the original triggers documentation.
BTW, there seems to be a typo in triggers.txt:
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.
AFAICS, the file trigger runs AFTER the file is modified. It would
not be very useful to run it before the file was modified!
--
see shy jo
Attachment:
signature.asc
Description: Digital signature