Re: understanding dpkg trigger cycles
[ CCed d-release. TL;DR: josch has created a list of packages that can
generate trigger cycles (13), I'm filing bug reports. ]
Hi!
On Thu, 2014-12-11 at 13:51:16 +0100, Johannes Schauer wrote:
> thanks a lot for your further explanations and clarifications!
Well, thanks a lot for doing the analysis!
> Based on this understanding I wrote a script which does the following:
>
> 1. calculate the set of packages A which declare an "interest" or
> "interest-await" file trigger (no explicit triggers) in their
> DEBIAN/triggers control file (Helmut supplied me with an initial list of
> binary packages to check from the data on lilburn)
>
> 2. calculate the dependency closure of all packages in the set A
>
> 3. for each package in A, check if it gets triggered by any of the paths
> provided by any of the packages in its dependency closure
>
> In summary, this finds some of the instances where a trigger cycle is created
> by an interested package directly or indirectly depending on a package which is
> put into triggers-awaited state for that particular package.
>
> Helmut helped me to limit the binary packages to search for DEBIAN/trigger
> files to 136 packages. After downloading and inspecting their content of
> DEBIAN/trigger, 48 packages remained which express an "interest" (without
> noawait) on a path.
(Sorry, I should have mentioned that I also had this information
available in lilburn. :/ )
> Out of those, it seems that 27 binary packages could potentially form a trigger
> cycle.
> The data is attached. The first column is the package containing the trigger.
> The second column is the path for which the trigger gets activated. The third
> column is a binary package that the binary package in the first column directly
> or indirectly depends on and which contains one or more files that trigger the
> package in the first column.
>
> Does this data look correct?
Yes, it does! I've excluded self-triggers though, as those are not
possible when path activated, because a package in an unpacked state
cannot accumulate pending triggers (sorry, should have mentioned that
before). Which gives a list of only 13 packages:
,---
apt-cudf
auctex
cups
fusionforge-plugin-mediawiki
gap-core
gxine
hoogle
icecc
libjs-protoaculous
mcollective
pypy
wordpress
xfonts-traditional
`---
I'll start filing bug reports.
BTW, would it be possible to have this generated, say once a week? I
assume the major roadblock here is the need to get an up-to-date list
of trigger control files? We could export a list from lilburn for
example?
Thanks,
Guillem
Reply to: