Re: (fwd) Draft spec for new dpkg "triggers" feature
Ian Jackson <firstname.lastname@example.org> wrote:
> Frank Küster writes ("Re: (fwd) Draft spec for new dpkg "triggers" feature"):
>> 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 have answered your `use case' already: you should see which file is
> causing the breakage, and who installed that file. The triggers
> mechanism is _not suitable_ because the information about `which
> package caused the trigger' is _wrong_ for this use case !
*I* do see it, *if* I manage to get updmap.log. The user sees it easier
if it is displayed by dpkg, and he'll more probably tell me this, by
just pasting dpkg's output in the bug report. Then I can easily try to
reproduce the bug myself, which is much easier than talking the user in
sending a log file he never heard about.
I also don't see how the information would be wrong. dpkg would say:
dpkg: trigger "foo" owned by package "bar" failed. This trigger has
been requested by the packages "baz-a, baz-b, baz-c".
It wouldn't claim that any of baz-* are responsible for the breakage, it
just gives a hint "try these if you want to reproduce the bug".
It would really make our life easier if we dpkg could be changed to
display this important information.
> Goswin von Brederlow writes ("Re: (fwd) Draft spec for new dpkg "triggers" feature"):
>> Frank Küster <email@example.com> writes:
>> > [bad idea deleted -iwj]
>> Bad idea. Say foobar 1.0 is installed already. Blafase 1.0 gets
>> installed and triggers foobar and fails due to a bug in foobar.
>> Now you want to install foobar 1.1 to fix the bug.
>> If dpkg runs the trigers again first then it will just fail again and
>> again and never update to a working foobar version.
> You are right that Frank's idea is a bad one but you are under the
> misapprehension that triggers ever get run `first'. They always get
> run last. That's the whole point.
No, he wasn't. My bad idea included that "misapprehension" as a new
Dr. Frank Küster
Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich
Debian Developer (teTeX/TeXLive)