Re: Bug#582109: debian-policy: document triggers where appropriate
Le Wed, Jul 17, 2013 at 09:27:19AM +0200, Raphael Hertzog a écrit :
> Julien is referring to this bug:
> It might be fixed for jessie, at least I hope so, but he seems to doubt
> > Also, if you think that triggers will give us problems for the Jessie release,
> > may I suggest that you give it a broad audience on debian-devel ? As a
> > maintainer of a package that has triggers, I am definitely interested to learn
> > if there is something I should give particular attention there.
> One of the main things to do is to switch as many packages as possible to
> use the interest-noawait directive when possible.
regarding “noawait” triggers, the patch already contains the following, which
is new and improved compared to the existing documentation.
The <tt>*-noawait</tt> directives should be used unless the
packages awaiting triggers can not satisfy <tt>Depends</tt>
relationships until the triggers have been processed.
After reading #671711 and /usr/share/doc/dpkg-dev/triggers.txt.gz, my
impression is that a package can not become "Unpacked" and keep a list of
pending triggers, because of the following statements in triggers.txt:
1) Pending triggers are marked "never" for "Unpacked" packages in the overview
2) The section "Details - triggered package" mentions that "packages in
‘config-failed’ or worse are never considered to have lists of pending
triggers". (Where config-failed means Half-Installed). In my understanding of
Dpkg states, Unpacked is "worse" than Half-Installed.
There are two consequences to this:
- "postinst configure" should do at least everything needed by
"postinst triggers", since in the situations where triggers are dropped,
the package is in a state that ensures that "postinst configure" will be run.
- we could write in section 6.5 of the Policy that for "postinst triggers"
the requirements are the same as for "postinst abort-*":
"The files contained in the package will be unpacked. All package
dependencies will at least be "Half-Installed" and will have previously been
configured and not removed. However, dependencies may not be configured or even
fully unpacked in some error situations."
I understand that changes in dpkg can enchance the mechanism to use triggers,
thus reducing the risk of having bugs, but I think that in #671711, dpkg is
following the specification, unless it failed to clear the list of pending
triggers when monodoc-browser became unpacked when it was upgraded.
Is that correct ? If yes, then I propose to go ahead and apply an improved
patch to the policy that mentions the restrictions and requirements on
"postinst triggers", because it represents an enhancement to the existing
Have a nice day,
Tsurumi, Kanagawa, Japan