[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

triggers question

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

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

Reply to: