understanding dpkg trigger cycles
Hi,
I figured out that I must have a misunderstanding with respect to trigger
cycles. Let me express my current understanding so that you can point out where
I got it wrong. Lets limit this to file triggers and exclude noawait triggers.
A package can be interested in a certain path through the "triggers" file in
its control archive. When another package shipping a file under that path gets
installed, then the package being interested in the path gets triggered. The
triggering package (the one providing the file) gets put into the
triggers-awaited state and the package that was interested in that path gets
put into the triggers-pending state.
Packages that are in the triggers-awaited state do not satisfy dependencies.
So if the interested package in the triggers-pending state directly or
indirectly depends on the package that triggered it (the one currently in
triggers-awaited state), then that package cannot get configured because:
- to configure the package in triggers-awaited state, the trigger has to be
resolved by the package in triggers-pending state
- to configure the package in triggers-pending state, its dependency on the
package in triggers-awaited state has to be resolved which cannot happen as
long as it is in triggers-awaited state
And this creates a cycle.
This is illustrated by the test case t-triggers-depcycle in the dpkg-tests
repository.
In that particular example, the package "pkg-trigger" gets into
triggers-pending state because it is interested in /test/trigger which is
provided by the package "pkg-files" which is put into triggers-awaited state
because of that. But because of that, the package "pkg-files" cannot satisfy
dependencies. But "pkg-files" depends on "pkg-trigger" which depends on
"pkg-files". So "pkg-files" cannot be installed because its transitive
dependency on itself cannot be satisfied.
Is this the correct explanation?
If so, I wonder why the error message says:
dpkg: cycle found while processing triggers:
chain of packages whose triggers are or may be responsible:
pkg-trigger -> pkg-trigger
packages' pending triggers which are or may be unresolvable:
pkg-trigger: /test/trigger
The package "pkg-files" is the one that fails to configure but it does not
appear in the error message?
Given that the above was more or less correct, I do not understand the test
case in t-triggers-depfarcycle.
In this scenario, the package "pkg-files" gets installed. The package ships the
file "/test/trigger/test-file" which triggers the package "pkg-trigger" which
is interested in "/test/trigger". The package "pkg-files" will be put into
triggers-awaited state while "pkg-trigger" gets into triggers-pending state.
Thus the package "pkg-files" cannot satisfy dependencies. The package
"pkg-files" depends on "pkg-depends-b" depends on "pkg-trigger" depends on
"pkg-depends-a" depends on "pkg-files". So how does the test case manage to
install the package "pkg-files" if it transitively depends on itself but should
not be able to satisfy that dependency because it is in triggers-awaited state.
Lastly, the examples in the dpkg-tests repository show situations in which a
fully dependency cycle of binary packages is created. But can a trigger cycle
not also occur without a full dependency cycle? Is it not enough if a package
"foo" (which is interested in path A) directly or indirectly depends on a
package "bar" (which provides something under the path A)? Why, in the test
suite, does "bar" also always depend on "foo"? Coincidence?
Thanks!
cheers, josch
Reply to: