Re: Bug#582109: debian-policy: document triggers where appropriate
Hi Charles,
On Sat, 11 May 2013, Charles Plessy wrote:
> I think that I took care of all of your comments.
>
> Here is an updated patch. Among the changes, it introduces
> sub-section to make the information easier to digest.
Thank you for the work! I have a few fixes and suggestions but otherwise
it looks mostly ready.
So seconded with the few suggestions below.
> + <p>
> + The <file>triggers</file> control file contains one directive per
> + line. Leading and trailing whitespace, everything after the first
> + hash character (<tt>#</tt>) on any line, and empty lines are ignored.
> + The following directives are supported.
> + <taglist>
> + <tag><tt>interest</tt> <var>trigger-name</var></tag>
> + <tag><tt>interest-noawait</tt> <var>trigger-name</var></tag>
> + <item>
> + Specifies that the package is interested in the named trigger.
> + The <tt>interest-noawait</tt> variant does not put the
> + triggering packages in the "Triggers-Awaited" state.
> + </item>
> +
> + <tag><tt>activate</tt> <var>trigger-name</var></tag>
> + <tag><tt>activate-noawait</tt> <var>trigger-name</var></tag>
> + <item>
> + Specifies that changes to this package's state will activate the
> + named trigger. The <tt>activate-noawait</tt> variant does not
> + put this package in the "Triggers-Awaited" state.
> + </item>
> + </taglist>
> + </p>
Here I would add a small paragraph recommending the usage of the -noawait
variants unless they are strictly required.
<p>The <tt>*-noawait</tt> directives should be used by default to avoid
putting packages in the "Trigger-Awaited" status. Packages should only end up
in this intermediary status when they are effectively broken until the
awaited triggers have been processed. A package in "Trigger-Awaited" does
not satisfy dependencies, for this reason an excessive and injustified amount of package
in this status can lead to early processing of triggers or even to dependency
loops.</p>
> + <p>
> + When a configured package activates a trigger, its state becomes
> + "Triggers-Awaited" instead of "Installed". For this package,
> + <prgn>dpkg</prgn> keeps a list, <tt>Triggers-Awaited</tt> of
missing comma after "Triggers-Awaited</tt>", but I would rather rewrite it
like this:
keeps a list of interested packages whose trigger processing is awaited
(that list is stored in the <tt>Triggers-Awaited</tt> field in dpkg's status
database)
> + interested packages whose trigger processing is awaited. Every
> + package in this list either has a nonempty list of pending
> + triggers, or is in "Half-Configured" or worse. When a package in
> + the state "Triggers-Pending" becomes "Installed", "Config-Files" or
> + "Not-Installed", its entry is removed from the
> + <tt>Triggers-Awaited</tt> lists of other packages.
> + </p>
> +
> + <p>
> + When a trigger is activated, the state of every interested package
> + becomes "Triggers-Pending". For each package, <prgn>dpkg</prgn>
> + keeps a list, <tt>Triggers-Pending</tt>, of triggers whose
> + processing is pending. Repeated activation of the same trigger has
Same suggested rewrite as above here.
> + no additional effect. In general a trigger will not be processed
> + immediately when it is activated; processing is deferred until it is
> + convenient.
> + </p>
> +
[...]
> + Packages in "Half-Configured" or worse never have pending triggers.
> + A package is only guaranteed to become notified of a trigger
> + activation if it is continuously interested in the trigger, and never
> + in "Half-Configured" or worse. A package whose postinst is being run
weird spacing here
> + can however acquire pending triggers during that run (ie, a package
> + can trigger itself).
> + </p>
> +
> + <p>
> + However, if such a package (between "Half-Installed" and
> + "Half-Configured" inclusive) declares some trigger interests then the
> + triggering packages will await their configuration (which implies
> + completion of any necessary trigger processing) or removal.
> + </p>
> +
> + <p>
> + For this reason, the <tt>postinst</tt> scripts it must do whatever
s/it//
> + actions are necessary to deal with any trigger activations when they
> + are called with <tt>configure</tt>.
> + </p>
> + </sect1>
> + </sect>
> </chapt>
Cheers,
--
Raphaël Hertzog ◈ Debian Developer
Get the Debian Administrator's Handbook:
→ http://debian-handbook.info/get/
Reply to: