Goswin von Brederlow <[EMAIL PROTECTED]> wrote: >>> Frank Küster <[EMAIL PROTECTED]> writes: >>> >>>> However, in this case an additional feature which I didn't find would >>>> be great: In case the triggered action fails and the package that was >>>> triggered is put into failed-config state, it would be very good to >>>> somehow be able to know: "Which package(s) activated the trigger?". >>>> [...] >>> >>> Say I install buggy-updmap-package first and then udpmap1-package and >>> udpmap2-package. >>> >>> The second time around the updmap would still fail and claim that >>> udpmap1-package and udpmap2-package triggered it. But both are not to >>> blame. >> >> There is no second time: If you install the three packages in one dpkg >> run, the trigger will be only run once. All three packages would then >> be listed as "has activated the failed trigger": That's better than >> none, since I only need to check these three packages and not all N >> installed packages that might activate the trigger. >> >> If you first install the buggy package in one run, you can't install the >> others, since they will depend on the package that contains updmap and >> provides the trigger, which will be failed-config. > > Unless they have no depends but just the trigger. > > Say foobar has a kde and gnome module for better integration into the > desktop. It would then just trigger the gnome or kde desktop hook if > any of them are installed. But it wouldn't depend on them.
Obviously there are several possible use cases, and you got a point here. On the other hand, this problem does not invalidate the wish to be informed which package(s) triggered and might be the cause, in particular considering your following suggestion: > I guess a failed trigger should leave the triggering package in a non > "installed" state as well so it retriggers on every configure run and > can be listed by dpkg as a source for failure. Yes, but it should be listed. Maybe the trigger itself should have a "failed" state, too. Then, if it is requested again, it will be run once first *before* new triggers are registered. This means that only the really buggy package will be in "failed-config" state, the others are just unpacked/half-configured. Regards, Frank -- Dr. Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX/TeXLive)
