Re: Draft spec for new dpkg "triggers" feature
Bernhard R. Link writes ("Re: Draft spec for new dpkg "triggers" feature"):
> [Ian Jackson <iwj@ubuntu.com>:]
> > * File triggers. These are activated automatically by dpkg
> > when a matching file is installed, upgraded or removed as part
> > of a package. They may also be explicitly activated by running
> > dpkg-trigger.
>
> I'm a bit fearfull about those type of triggers. Triggers can be become
> quite a hassle when they are triggered too general and run when they
> are not needed.
We don't have any triggers yet, so I don't understand how you can say
that they "can become quite a hassle".
> And allowing packages to just listen for some file or directory feels
> like encouraging half-backed solutions.
It reduces the amount of stuff that needs to be precisely coordinated
between different packages; explicit triggers need the trigger names
to be coordinated as well as everything else.
> > A file trigger is guaranteed to be activated before the file in
> > question is modified by dpkg; on the other hand, a file trigger might
> > be activated even though no file was actually modified.
>
> What does that garantee? That no modification can be missed if dpkg
> is interupted before finishing?
Yes.
> What's the advantage in doing so?
It will avoid situations where the interested package is broken
because (for example) some data it previously registered has
disappeared.
> > 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.
>
> Isn't that a bit often to trigger? I definitly think there should
> be some limit, like only if passing the workable/non-workable border.
Since triggering is idempotent, the concept "too often" seems
irrelevant, really. In nearly all normal operations a package changes
sufficiently that the trigger ought to be activated; the only question
is whether to activate the trigger for aborted operations or other
kind of weirdness.
> I'd also prefer a way so that if programs get better they can avoid
> work in the future, if only some updated have to be done depending on
> what changed. Like when only a new menu-provider appears for
> update-menu, there is no reason to recreate all menus, but only the
> one that is new. Or some other program could detect that only some file
> vanished and could just remove all information for that package without
> reparsing and reprocessing all information.
This can be done using file timestamps.
> To avoid being something like that impossible by design, having a way
> to specify a trigger happened and the names of the packages (or other
> free-form data given to a explicit trigger call) handed to the trigger
> processor.
I thought about something like this. But it makes activating a
trigger no longer idempotent (because of this additional data which
needs to be carried about), and it will also be quite cumbersome to
constantly have to record and pass about the ancilliary data.
Ian.
Reply to: