[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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.


Reply to: