Bug#582109: debian-policy: document triggers where appropriate
Thanks again Raphaël for your prompt feedback.
Le Thu, Jul 18, 2013 at 09:00:44AM +0200, Raphael Hertzog a écrit :
>
> On Thu, 18 Jul 2013, Charles Plessy wrote:
> >
> > - "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.
>
> Yes, that's pretty important. I haven't checked if this was already
> documented in your patch, but it definitely is a clear rule in the
> /usr/share/doc/dpkg-dev/triggers.txt.gz.
The current patch adds the following to the paragraph describing "postinst
configure" in section 6.5.
Even when called with <tt>configure</tt>, this script must do whatever actions
are necessary to deal with any <qref
id="dpkg-triggers-intermediate-states">triggers</qref> activation.
This is repeated at the end of the new section on triggers.
For this reason, the <tt>postinst</tt> scripts must do whatever
actions are necessary to deal with any trigger activation when they
are called with <tt>configure</tt>.
> > - 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."
>
> Why not, but then please add a footnote explaining that this ought to be
> temporary until the dpkg bug gets fixed. Because it's not really a
> satisfactory situation.
Can you explain what the bug is and what the correction will be ? Because I
have the impression that the root of the problem is only that the current
documentation is misleading, and that dpkg does exactly what it is expected.
>From the documentation:
Packages in t-awaited and t-pending demand satisfaction of their
dependencies just like packages in installed.
The misleading point is "just like packages in installed". In my
understanding, when a package is upgraded, the packages that depend on it stay
in the "Installed" state while the new version of the upgraded package is
unpacked and configured. Not just the triggers, but also any other command not
related to the dpkg or apt session that would happen to run at that time can
fail if they strictly require a function that is not available between unpack
and configure.
I do not see any other solution than applying the same restrictions on
"postinst triggered" as for "postinst configure". (PS: after reading the
thread again, I just noticed that this also what you wrote in #671711#68).
(PPS: By the way, apart from Manoj's excellent diagrams at
<http://people.debian.org/~srivasta/MaintainerScripts.html#sec-3.4.3>, is there
an extensive documentation on how package upgrades are handled by APT and Dpkg ?)
In the case of #671711, I wonder if monodoc-browser is simply abusing the
triggers mechanism, since the only thing that its postint script does when
called with "configure" is to trigger itself.
Altogether, I propose to document that the requirements are the same for
"postinst triggered" as for "postinst configure", and go ahead with updating
the Policy. In my understanding, the proposed improvements to Dpkg can reduce,
but not completely eliminate, the cases where fragile postinst scripts break
when triggered.
Have a nice week-end,
--
Charles Plessy
Tsurumi, Kanagawa, Japan
Reply to: