Hi, On Thu, 18 Jul 2013, Charles Plessy wrote: > 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 > table. > > 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.
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. > - 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. > 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. The documentation says "Packages in t-awaited and t-pending demand satisfaction of their dependencies just like packages in installed.". This is the part that is not respected in the above bug. So no, it's not really following the specification. > 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 > documentation. Definitely. jessie development is live, we want to draw the attention of people to review their triggers and do the right thing. Cheers, -- Raphaël Hertzog ◈ Debian Developer Discover the Debian Administrator's Handbook: → http://debian-handbook.info/get/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org