Re: Draft spec for new dpkg "triggers" feature
* Ian Jackson <iwj@ubuntu.com> [070130 18:26]:
> Concepts
> --------
>
> Each trigger is named, and at any time zero or more packages may be
> interested in it.
>
> We currently envisage three kinds of triggers:
> * Explicit triggers. These can be activated by any program
> by running dpkg-trigger (at any time, but ideally from a maintainer
> script).
> * 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.
And allowing packages to just listen for some file or directory feels
like encouraging half-backed solutions.
> File triggers
> -------------
> File triggers should not generally be used without mutual consent.
> The use of a file trigger, and the name of the trigger used, should be
> stated in policy, so that a package which creates a relevant file in a
> maintainer script can activate the trigger explictly.
I'd almost suggest that official packages should not listen for file
triggers at all and always rely on explicit triggers. (If a package
adds or modifies a file, it should know that and thus can trigger
explicitly, and things like lintian/linda can easily make sure that
cases a automatic trigger would help anything have no real chance to
exist).
> 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? What's the advantage in doing so?
(I could imagine a garantee that a trigger is not activated before
the package triggering it is configured properly could be useful,
but what is the use for this garantee?)
> Package declarations regarding triggers
> ---------------------------------------
> [...]
> 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.
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.
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.
Hochachtungsvoll,
Bernhard R. Link
--
"Never contain programs so few bugs, as when no debugging tools are available!"
Niklaus Wirth
Reply to: