Re: understanding dpkg trigger cycles
Quoting Guillem Jover (2014-12-11 20:38:53)
> Could you also take into account explicit triggers that get activated through
> activate and activate-await directives? :) It would be a matter of matching
> those with the interest(-await) directives.
Sure! That was the plan after having confirmed that what I did for the file
triggers was correct :)
> The only remaining cycles would be the ones activated via dpkg-trigger, which
> could probably be detected later on only as an approximated heuristic.
For this, Helmut gave me a list of binary packages which have maintainer
scripts that contain the string "dpkg-trigger". There are 9 source packages
that build binary packages with a direct dpkg-trigger invocation in the
maintainer scripts of one of the binary packages they build:
glib2.0, glx-alternatives, guile-1.8, guile-2.0, gxine, librsvg, pdns, perl,
I plan to create a heuristic which is hopefully able to check for most cases
whether or not dpkg-trigger was called with or without --no-await and which
trigger was activated by it. Hopefully most people wrote their dpkg-trigger
invocations in a single line ;)
In addition, going through a codesearch results for dpkg-trigger, we figured
out that there are some more applications that call dpkg-trigger.
The following seem to call dpkg-trigger but with --no-await so they are not
interesting for us: update-python-modules, ldconfig, update-initramfs
The following seem to call dpkg-trigger without --no-await and might be useful
to detect when used in maintainer scripts.
When searching for binary packages that have one of above strings in their
maintainer scripts, we got a list of 1901 binary packages or 1692 source
packages that build them (list omitted for brevity).
> (I can provide the list of trigger files with contents if you want, so that
> you don't need to download them all.)
I made this the topic of the other mail.