Re: (fwd) Draft spec for new dpkg "triggers" feature
Frank Küster writes ("Re: (fwd) Draft spec for new dpkg "triggers" feature"):
> Ian Jackson <ian@davenant.greenend.org.uk> wrote:
> > 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.
So have your machinery squirt updmap.log to stderr at the appropriate
point and voila! it will appear in front of the user for their
delectation and delight.
> 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".
As explained previously, the packages that would be listed might be
unrelated to the one that was the cause.
> > 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
> "misfeature".
The main point of triggers is to allow things to be run late so that
multiple activataions can be aggregated. Running triggers first would
defeat that.
Ian.
Reply to: