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

Re: Draft spec for new dpkg "triggers" feature



James Westby writes ("Re: Draft spec for new dpkg "triggers" feature"):
> On (30/01/07 17:08), Ian Jackson wrote:
> >  activate <trigger-name>
> > 
> >     Arranges that any change of the package's state will activate the
> >     specified trigger.  The trigger will be activated just before the
> >     package state changes.
> 
> Could you please clarify this a little for me. The activate is for the
> non-file triggers correct?

No, you can activate any trigger by specifying its name.

>  When you say "any change of the package's state" does this really
> mean any change, as in will it trigger multiple times on package
> install, for purged -> half-installed -> installed?

Yes.

>  If so does this actually cause the trigger to run more than once,
> or do triggers by their nature only run once in this case even
> though they are activated many times.

The latter.

> Another example use case for you.  [ stuff about mcs-manager -iwj ]
> 
> One of the maintainers has been thinking about ways to only do this once
> per upgrade to minimise it, but never really came up with a good
> solution, and even thought about just disabling it and leving the
> plugins messed up until an X restart was done.
> 
> It seems like triggers would be perfect for this, and would be
> appreciated by me at least to avoid this issue, and others.

Absolutely.

> This could be done (or at least could be made to) with a file trigger I
> believe, but for the sake of argument say it isn't.

OK.  (A file trigger would usually be better because it doesn't
require any special measures in the plugin packages.)

> The refresh only needs to be done if one plugin makes it to the
> installed stage, anything else is a waste, but not an actual problem.

You can get more fine-grained control if you invoke dpkg-trigger in
your maintainer script.  But in general the triggers design errs on
the side of invoking a trigger when it might not be necessary rather
than failing to invoke it when it might be needed, since the former is
just an annoyance and the later could be a serious headache.

Ian.



Reply to: