Re: (fwd) Draft spec for new dpkg "triggers" feature
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 !
> 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.
I'm not convinced that building a blame-transfer system into the
package manager is a good idea! That's a recipe for maintainers
playing core wars on users' systems (even more than they do already :-/.)
Goswin von Brederlow writes ("Re: (fwd) Draft spec for new dpkg "triggers" feature"):
> Frank Küster <frank@kuesterei.ch> 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.
A failing postinst (which is what a failing trigger is)( does not
prevent a package being unpacked.
Ian.
Reply to: