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 -- To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141210213501.15300.72671@hoothoot
