The policy needs to be updated to take into account the dpkg triggers. At
the very least it needs to document the new invocations of the postinst in
chapter 6 (postinst triggered ...) see
/usr/share/doc/dpkg-dev/triggers.txt.gz

and for those who want a slightly less dense description, i wrote something
up a while back that you can feel free to borrow from:

http://www.seanius.net/blog/2009/09/dpkg-triggers-howto/

(though i am not volunteering to do the policy writing myself)

	sean

and for those who want a slightly less dense description, i wrote something
up a while back that you can feel free to borrow from:

http://www.seanius.net/blog/2009/09/dpkg-triggers-howto/

(though i am not volunteering to do the policy writing myself)

	sean

Le Tue, May 18, 2010 at 02:50:02PM +0200, Raphaël Hertzog a écrit :

I am having a look at how to document triggers.  In order to simplify the
explanation and re-use more easily material from the file above, I think
that we would benefit from documenting the dpkg states for a package.

The manual page of dpkg-query indicates:

 - Not-installed
 - Config-files
 - Half-installed
 - Unpacked
 - Half-configured
 - Triggers-awaiting
 - Triggers-pending
 - Installed

The documentation in /usr/share/doc/dpkg-dev/triggers.txt.gz also
mentions config-failed.  I will look for a comprehensive list but
if you already have the answer one please let me know.

I wonder where to add this information: either in chapter 3 (binary packages)
or chapter 6 (Package maintainer scripts and installation procedure).

What do you think ?

Have a nice Sunday,

Le Sun, Feb 24, 2013 at 04:41:55PM +0900, Charles Plessy a écrit :

How about adding the following to the Policy's section 6.1 (Introduction to
package maintainer scripts) ?

          Dpkg defines the folowing states for the packages.
          <taglist>
            <tag><tt>not-installed</tt></tag>
            <item>
              The package is not installed or has been purged.
            </item>

            <tag><tt>config-files</tt></tag>
            <item>
              The package has been removed; its configuration files remain.
            </item>

            <tag><tt>half-installed</tt></tag>
            <item>
              Errors happened during installation, upgrade or removal.  Solving
              them requires the package to be re-installed.
            </item>

            <tag><tt>unpacked</tt></tag>
            <item>
              The files contained in the package have been successfuly unpacked,
               but the maintainer scripts have not been executed.  Thus, the
               files created by the maintainer scripts are not yet available.
            </item>

            <tag><tt>half-configured</tt></tag>
            <item>
              The package has been unpacked, and an error occured during the
              execution of one of its maintainer scripts.
            </item>

            <tag><tt>triggers-awaited</tt></tag>
            <item>
              The package has been unpacked and configured, and its
              installation activated some <prgn>dpkg</prgn> triggers that have
              not yet been executed.
            </item>

            <tag><tt>triggers-pending</tt></tag>
            <item>
              Some triggers handled by this package have been activated and are
              not yet executed.
            </item>

            <tag><tt>installed</tt></tag>
            <item>
              The package is installed, no further action is required.
            </item>
          </taglist>

For the half-installed and half-configured, I am not very confident on what I
wrote and surely feedback.

Have a nice week-end,

Dear all,

pasting a lot from /usr/share/doc/dpkg-dev/triggers.txt.gz and deb-triggers(1),
I have drafted a patch to the Policy to document triggers.

Your comments are very welcome.

Have a nice week-end,

Hi!

This is documented in the dpkg man page (PACKAGE STATES), sorry for
not mentioning this before.

We unified the states in policy to be all capitalized some time ago,
I think it would make sense to follow that convention to not confuse
the terminology usage.

I'm not sure, if we should mention how to transition from/to states in
this description, doing that in a dedicated section on how those
transitions happen might be better (this re to the “has been purged”).

Related to state transitions, I'd talk about the current state (is) not
how we got there (has been), here and in all other state descriptions.

... or removed. Same comment about state transitions.

Configuration might involve changing existing files, or changing
parameters through existing APIs that change, say, a database on the
backend for example, so I'd avoid explicitly mentioning that files
might not be available, as that's not really comprehensive.

Same comment about state transitions. This state could also happen during
removal for example.

I'd say that the triggers need to be processed, and not executed. Also
do we need to say that those are dpkg triggers, I'd say they are just
package triggers.

Same comment about executed → processed.

The “no further action is required” seems a bit confusing, to me it
reads as there's nothing else to be done to the package ever again,
not even upgrades or removals. :)

Hope that helps.

Thanks,
Guillem

Hi Guillem,

thank you for your comments (some quoted below).

Le Sat, Mar 02, 2013 at 03:37:36PM +0100, Guillem Jover a écrit :

To simplify things as suggested, I pasted the text from dpkg's manual page
(only changing "your system" to "the system", and removed "OK".) to the
proposed addition to the Policy.

I also corrected capitalisation.  Can you do the same in the manual pages ?
For the markup of the state names, while I am not completely satisfied with
having them flanked with quotes instead of either italics or monospaced, I
think that we can defer this to the next major release of the Policy.

I attached an updated  patch.

Have a nice day,

Hello everybody,

I am still seeking comments for the attached patch, that describes Dpkg
triggers.

Have a nice day,

Le Fri, Mar 15, 2013 at 04:11:19AM +0100, Guillem Jover a écrit :

Thanks Guillem,

like the other enhancements to the Policy, there is nothing that is strictly
urgent.  However, I worked with passion on this patch, and I would be very
pleased if others could also have a look at it.

In particular, for others who would think that it is be better for such a
technical patch that the final seconding comes from people who know dpkg very
well, I agree, but please do not hesitate to make comments if you see defects,
unclear or missing parts, possible improvements, etc.

Have a nice day,

Hi Charles,

Here are my comments. There's quite a bit of work left.

"the <file>triggers</file> file"
(invert two words)

the triggers file (see man deb-triggers) can contain "interest" directives
but also "activate" ones. So this needs to be reworded.

For example “the triggers file wich defines the package's interaction with
dpkg's trigger system”

I would use the precise states listed in dpkg(1), i.e. entirely in
lowercase. (same for all the states)

I don't think that it's marked "config-failed" to not retry the trigger
processing. It's just that we need an error state and that config-failed
can be reused for this purpose precisely because anything done by trigger
processing is supposed to also be done during normal configuration (so it
is effectively retried on next configure).

“In case of failure the package's state becomes <tt>config-failed</tt>,
and the task associated to the trigger processing will be completed by
the <tt>postinst configure</tt> during the next package's configuration.”

s/can be can be/can be/

“<prgn>dpkg</prgn> triggers allows packages to monitor events caused by
the installation, upgrade or removal of packages. Monitoring packages are
said to be <em>interested</em> in some triggers. On the other side,
triggers must be <em>activated</em> to record the event notification on
the <em>interested package</em>. The latter is then said to have
<em>pending triggers</em> and the <em>activating</em> package (if any) is
said to await the processing of the trigger.

Thanks to this feature, it's easy to avoid duplication of processing logic
among packages by implementing it in one package and making sure that all
other packages rely on triggers to execute the wanted code.”

The triggers file can contain "activate" directives too so I'd suggest
to be more explicit:

“For a package to declare its interest in a trigger, it must include one of
the <tt>interest</tt> directives in the <file>triggers</file> file in its
control archive.”

Then start a new paragraph describing the syntax of the triggers
file.

Useless leading whitespaces on this line.

whitespaces ? (with "s")

I'm not sure that you need to explain each time that the interested
package doesn't get added to the Triggers-Awaited field. This is just
an implementation detail of the triggers-awaited state. When we put
something in triggers-awaited, we must remember which package
needs to have its triggers processed. And we already explain it later.

+are

missing parenthesis ")".

And you must indicate that explicit triggers can also be activated by
state changes of packages having an "activate" directive in their
triggers control file.

This whole paragraph about symlinks is not at its place here. Or if you
want to keep it here, put it in a footnote so that it doesn't distract the
high level overview that this section is about.

The name of a file trigger is...

s/by/be/

…keeps a list of interested packages whose trigger processing is awaited
in the <tt>Triggers-Awaited</tt> field.

…keeps a list of triggers whose processing is pending in the
<tt>Triggers-Pending</tt> field.

Also you mix states written as <tt>config-failed</tt> with states
written as "Triggers-Pending". I suggest you standardize on the former.

interested

I would add "(unless --no-triggers has been used).".

s/made the package go to/marked the package as/

This whole section is made of many paragraphs grabbed from
various parts of /usr/share/doc/dpkg-dev/triggers.txt.gz and
really lacks a bit of structure. You should try to add some sub-sections
and group stuff by topics.

“or is in <tt>triggers-pending</tt> state,”, no ?

s/postinst triggers/postinst triggered/

Cheers,

Raphael Hertzog <hertzog@debian.org> writes:

I thought Guillem requested we use the capitalized versions.  I think the
capitalized versions stand out more and make it clearer that the expected
meaning isn't necessarily the plain English meaning of the phrase.

Ok, but then we ought to be consistent and avoid usage of
<tt>config-files</tt> or <tt>config-failed</tt> and other similar mention
of states elsewhere.

BTW, I just notice that <tt>config-failed</tt> in the text was wrong and
should refer to "Half-Configured".

Cheers,

s/folowing/following

Cheers,

Le Wed, Apr 10, 2013 at 12:07:19PM +0200, Raphael Hertzog a écrit :

Thanks a lot Raphaël and everybody !

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.

Cheers,

Hi Charles,

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.

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>

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)

Same suggested rewrite as above here.
[...]

weird spacing here

s/it//

Cheers,

Hi Raphaël,

thanks for the quick feedback.

In the list of directives, I have moved the "noawait" variant on top to
better show that they are the default choice.  I also reworded your suggestion
to make it a positive recommenation: use "interest" and "activate" only
if you want to put the triggering package in "Trigger-Awaited" state.

Le Sat, May 11, 2013 at 03:09:25PM +0200, Raphael Hertzog a écrit :

Here is my proposition:

        <heading>Syntax</heading>

          <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-noawait</tt> <var>trigger-name</var></tag>
              <tag><tt>interest</tt> <var>trigger-name</var></tag>
              <item>
                Specifies that the package is interested in the named trigger.
                The <tt>interest</tt> variant puts the triggering packages in
                the "Triggers-Awaited" state, and the <tt>interest-noawait</tt>
                variant does not.
              </item>

              <tag><tt>activate-noawait</tt> <var>trigger-name</var></tag>
              <tag><tt>activate</tt> <var>trigger-name</var></tag>
              <item>
                Specifies that changes to this package's state will activate the
                named trigger.  The <tt>activate</tt> variant puts this package
                in the "Triggers-Awaited" state, and the
                <tt>activate-noawait</tt> variant does not.
              </item>
            </taglist>
          </p>

          <p>
            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.
            In that case, the <tt>interest</tt> or <tt>activate</tt> directives
            should be used, as they will put the triggering packges in the
            "Triggers-Awaited" state, which does not satisfy dependencies.
            Note that pakcages unnecessarly entering this state can cause the
            early processing of triggers or even dependency loops.
          </p>

I also added "through the <tt>interst</tt> or <tt>activate</tt> directives"
after "When a configured package activates a trigger".

I applied the other changes you proposed as well, with minor rewording:

-           <prgn>dpkg</prgn> keeps a list, <tt>Triggers-Awaited</tt> of
-           interested packages whose trigger processing is awaited.  Every
+           <prgn>dpkg</prgn> keeps a list of interested packages whose trigger
+           processing is awaited, which is stored in the
+           <tt>Triggers-Awaited</tt> field in dpkg's status database.  Every

I attached an updated version of the patch.

Cheers,

Hi,

s/pakcages/packages/

Thanks, I agree that your improved wording is better. Seconded.

Cheers,

Le Sun, May 12, 2013 at 10:09:17AM +0200, Raphael Hertzog a écrit :

Thanks again.

Guillem recently posted on debian-devel about "noawait" triggers, and I would
like to send a link to the patch to the Policy once it gets futher
proof-reading and seconds.  Or if it takes time, shall I point to this bug log
on -devel ?

Cheers,

Hi,

I don't see any harm to mentioning it right now. And maybe point Ian
Jackson to it, he might want to review and second it...

Cheers,

Le Sun, May 12, 2013 at 10:09:17AM +0200, Raphael Hertzog a écrit :

Dear all,

now that Wheezy is released, I hope that everybody has more time to review the
patch to integrate triggers in the Policy and confirm Raphaël's seconding or
propose extra corrections or improvements.

http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=87;filename=policy-triggers.diff;att=1;bug=582109

Have a nice day,

tag 582109 patch
thanks

Le Thu, Jul 04, 2013 at 11:26:01AM +0900, Charles Plessy a écrit :

Dear all,

I would like to give a firmer call for seconds, so that we can close this issue
and move to the next big change: either multi-arch, or the conversion to
DocBook XML.

Have a nice day,

Charles

That patch has a bunch of typos (I noticed a few in spelling "package").

Also it doesn't seem to warn against triggers being called with Depends
not satisfied, which caused no end of trouble for upgrades to wheezy,
and which is probably going to bite us again for jessie.

Cheers,
Julien

Le Tue, Jul 16, 2013 at 05:09:08PM +0200, Julien Cristau a écrit :

Hi Julien,

thank you for your comments and sorry for forgetting to run a spellchecker.  I
will make the following spelling corrections.

    s/wich/which/
    s/activations/activation/
    s/packges/packages/
    s/unnecessarly/unnecessarily/
    s/mechanims/mechanism/

About the problem of triggers being called with Depends not satisfied, can you
give more explanations or suggest some text for the warning ?  Would it be
enough to add a notice that the triggered postinst script may be called when
the package is "Unpacked", which is a state that does not require that the
packages that are depended on are configured ?

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.

Have a nice day,

Hi,
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=671711

It might be fixed for jessie, at least I hope so, but he seems to doubt
it.

One of the main things to do is to switch as many packages as possible to
use the interest-noawait directive when possible.

Cheers,

Le Wed, Jul 17, 2013 at 09:27:19AM +0200, Raphael Hertzog a écrit :

Hi all,

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
    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.

 - 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
documentation.

Have a nice day,

Le Thu, Jul 18, 2013 at 08:55:20AM +0900, Charles Plessy a écrit :

By the way, are the “noawait” triggers guaranteed to be executed only after the
triggering package has entered the "Installed" state, or can they be executed
at the same time of other triggers as well ?

Cheers,

Le Thu, Jul 18, 2013 at 08:55:20AM +0900, Charles Plessy a écrit :

Cheers,

There's no such guaranty. A package that triggers another package only
knows that the triggers will be processed at some point in the future. It
doesn't know if if will before or after its own configuration (the
"noawait" doesn't change anything here except that the trigger requirement
is not recorded).

Even with traditional triggers, it's possible that dpkg will configure a package
before processing the triggers that it awaits. What this means is just
that the end status will be "Triggers-Awaited" instead "Installed".

Cheers,

Hi,

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.

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.

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.

Definitely.

jessie development is live, we want to draw the attention of people to
review their triggers and do the right thing.

Cheers,

Thanks again Raphaël for your prompt feedback.

Le Thu, Jul 18, 2013 at 09:00:44AM +0200, Raphael Hertzog a écrit :

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>.

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,

The bug is that triggers are run while the dependencies of the triggered
package are not satisfied. The fix is not to do that and wait until those
dependencies are satisfied (but guillem mentionned that it also needs some
cycle breaking code).

That's true but it's not really comparable. "postinst triggered" ought to
work like "postinst configure" and there you have the guaranty that the
dependencies are configured.

I did not write that. On the contrary, re-read:

“The problematic fix is to ensure the same requirements for "postinst
triggered" as for "postinst configure". But we could enforce some
requirements that would probably solve the issues we saw without
introducing cycles.”

There are no "restrictions" for "postinst configure" (you can rely on
dependencies — except if you have a dependency cycle) and there should be
no restrictions for "postinst triggered". But right now, dpkg doesn't
ensure anything. And instead of nothing checked by dpkg, I suggested to
ensure some requirements nevertheless but which are less demanding than
those used by "postinst configure".

I know https://wiki.debian.org/MaintainerScripts too but that's all.

Cheers,

Le Sun, Jul 21, 2013 at 09:36:52PM +0200, Raphael Hertzog a écrit :

Sorry for the poorly chosen use of the word "restrictions" here...

Nevertheless, please let me try to refocus on the question of whether
the Policy can be updated or not.

Here is what is written in the Policy about "postinst configure":

    The files contained in the package will be unpacked. All package
    dependencies will at least be unpacked.

The corollary is that there is no guarantee that the dependencies will be
configured, and my understanding of #671711 is that it currently applies to
"postinst triggered" as well.

I propose to go ahead with the following:

            <tag><var>postinst</var> <tt>triggered</tt>
              "<var>trigger-name</var> <var>trigger-name</var> ..."</tag>
            <item>
              The files contained in the package will be unpacked.  All
              package dependencies will at least be "Unpacked"<footnote>
              There is work under way on <prgn>dpkg</prgn> to ensure that
              the requirement on <tt>postinst triggered</tt> is less demanding
              than for <tt>postinst configure</tt>, see the bug number
              <url id="http://bugs.debian.org/671711" name="671711"> for
              details.</footnote>.


I attached a full version of the latest patch.

I would like to go ahead and close this bug.  If Raphaël confirms that he still
seconds the patch,  I would much appreciate if I could either have support or
actionable objection from others (preferably in the form of "unless X is done,
the patch should not be applied", rather than "it would be good to do Y").

Have a nice day,

I believe we can update the policy whatever the status of this specific
bug.
circular dependencies involved, all package dependencies will be
configured.”

My suggestion:

<prgn>postinst configure</prgn> was already run and the dependencies ought
to be configured. However, dpkg currently suffers of a bug which means
that <prgn>postinst triggered</prgn> can be called while some dependencies
are being upgraded (see bug <url id="http://bugs.debian.org/671711"
name="671711">). You should thus only rely on the fact that the
dependencies are at least unpacked and were already configured once
(similar to what <tt>Pre-Depends</tt> ensures for <prgn>preinst</prgn>
maintainer scripts).

I maintain my second provided that you fix the above.

Cheers,

Le Mon, Jul 22, 2013 at 09:00:59AM +0200, Raphael Hertzog a écrit :

Ahem... That is embarassing.  Thanks for your patience.  Now I understand why I
did not understand.

Great, and thanks for your suggestion, which I will apply.

More seconds or objections from others ?  What are the other Policy editors
thinking about this patch ?

Cheers,

It doesn't really matter whether it's fixed for jessie.  Since it's not
fixed in wheezy, it's relevant for packages in jessie when they're
upgraded.

Cheers,
Julien

Le Wed, Jul 24, 2013 at 03:58:04PM +0200, Julien Cristau a écrit :

Hi Julien,

does the current patch (attached) address your concerns ?  If yes, would
you second it ?

The paragraph on "postinst triggers" is now as follows.

	postinst configure was already run and the dependencies ought to be configured.
	However, dpkg currently suffers of a bug which means that postinst triggered
	can be called while some dependencies are being upgraded (see bug 671711).
	Until this bug is absent from the stable release, you should thus only rely on
	the fact that the dependencies are at least unpacked and were already
	configured once (similar to what Pre-Depends ensures for preinst maintainer
	scripts). postinst triggered processes one or more triggers that this package
	is interested in. In case of failure the package's state becomes
	"Half-Configured" and the task associated to the trigger processing will be
	completed by the postinst configure during the next package's
	configuration[48].

Have a nice day,

Le Thu, Jul 25, 2013 at 08:00:55AM +0900, Charles Plessy a écrit :

Hi all,

I would like to make one more call for feedback.

Needless to say, I am annoyed that despite we had mutiple persons who commented
in that thread, and five Policy editors with a fresh delegation, nothing is
moving forward.  Julien, Guillem, could you confirm if we can go ahead without
further input from you ?  To the other Policy editors: given the glacial pace
of the work, would it possible for at least one of you to book one hour in your
calendar within for instance the next two months, to ensure that one more
person can be in position of seconding the patch or requesting further
corrections ?

Have a nice week-end,

Sorry, I don't feel confident to second anything trigger-related.

Cheers,
Julien

Charles Plessy wrote:

Sorry for the long silence.

My feeling is that the patch is not ready yet.  I know that without some
more specific list of concerns that is not a very useful thing to say,
but that's what I have.  In other words, I don't think it's ready for
seconds.

If I end up with time to work on it, what I would probably do is to
split the patch into smaller changes that can be considered and
applied independently, which would hopefully be less intimidating for
area experts to review.

For example, a patch adding documentation of the non-trigger Dpkg
states and how the package installation procedure interacts with them
should be uncontroversial and easy to review.

With triggers, one of the hardest parts to document is how packagers
are supposed to deal with the "dependencies may not be configured"
bug.  Mentioning the bug as you have is good, but giving some
practical advice about how to work around it ("Do not rely on a sane
state being present" is not practical advice because it doesn't say
what to do when your dependencies are missing) would be better.  Maybe
policy should only define the -noawait variant for now?

Thanks, and sorry I do not have something more useful to offer,
Jonathan

Le Sat, Aug 03, 2013 at 09:41:59AM -0700, Jonathan Nieder a écrit :

Hi Jonathan,

I have split the patch in the following parts:

	0001-Document-Dpkg-states.patch
	0002-Document-postinst-triggered.patch
	0003-Document-concepts-syntax-and-control-information-fil.patch
	0004-Detail-the-two-trigger-kinds-explicit-and-file.patch
	0005-Details-about-Dpkg-states-when-processing-triggers.patch
	0006-Document-the-behaviour-of-triggers-when-packages-are.patch

I could not cut in smaller pieces, as it would separate informations that would
lose a lot of context if they are not added together.

In the current patch, the -noawait variant is recommended.  I think that the
Policy should not hide information about a feature in the hope that less people
use it.  I think that it is important that the Policy stays a neutral
reference.

About the Dpkg bug, I think that we should consider the whole section about the
postinst script.  In the paragraph above the description of "postinst
triggered" it already mentions "consider the correct error handling approach if
those actions fail".  I think that this is also the current practice for
"postinst configure", where often I sed that commands are tested for their
availability before being run.  Lastly, the current patch also mentions
"Pre-Depends", which is a robust last-ressort solution.

In the existing documentation of the dpkg triggers, the bug of dpkg is not
mentionned, so I think that this patch to the Policy represents a progress
compared with the current situation.  I still do not understand why there is so
much reluctance in enhancing our documentation.

Have a nice Sunday,

Le Sun, Aug 04, 2013 at 09:14:09AM +0900, Charles Plessy a écrit :

Hi Jonathan and everybody,

how about starting with 0001-Document-Dpkg-states.patch ?  It documents the
Dpkg states without intrusive normative changes.

Have a nice day,

Le Fri, Aug 23, 2013 at 12:44:36PM +0100, Ian Jackson a écrit :

We have not changed the semantics compared to the current documentation (that
includes the "noawait" variants that were not present in the original
proposal).  The documentation in the Policy brings together informations from
deb-triggers(5), dpkg-trigger(1) and /usr/share/doc/dpkg-dev/triggers.txt.gz.
Most of the text is a direct copy or adaptation from these three documents,
plus an extra paragraph listing the Dpkg states, taken from dpkg(1).  From
/usr/share/doc/dpkg-dev/triggers.txt.gz, I left out the historical details
(plan for transition, etc.), implementation details, discussions regarding apt,
etc., basically most of the text after the section "File triggers".

The latest patches are in the following message in the BTS.  If you had time
to review them, that would be great !

http://bugs.debian.org/582109#209

Cheers,

Le Fri, Aug 16, 2013 at 10:10:51AM +0900, Charles Plessy a écrit :

Hi all,

this is the last call for integrating Dpkg triggers in the next update of the
Policy.  (3.9.5), that I inted to upload before the end of October.

Cheers,