On Fri, 2018-08-03 at 10:45 +0200, Guillem Jover wrote: > Hi! > > On Thu, 2018-07-19 at 01:03:04 +0100, Ben Hutchings wrote: > > Package: dpkg-dev > > Version: 1.19.0.5 > > Severity: normal > > > For explicit triggers, both the interested and activated packages can > > specify "await" or "noawait". I could not understand from the current > > documentation what is supposed to happen if the two specify the > > opposite. > > > > Looking at the source, I think that the triggering package will only > > await the trigger if both specify "await" (or don't specify either > > way). > > Would the attached patch help? Would have you looked here, or do you > think adding references from somewhere else would also help? For the > deb-triggers(5) part I'm not sure which is more clear if the inlined > description in the directives or the general one at the end. Depending > on which, I might perhaps not keep both.
I believe I read both of these manual pages, and I think this patch would made things clear to me. I just have some comments on the wording: > --- a/man/deb-triggers.man > +++ b/man/deb-triggers.man > @@ -43,9 +43,17 @@ The trigger control directives currently supported are: > .IP > Specifies that the package is interested in the named trigger. All > triggers in which a package is interested must be listed using this > -directive in the triggers control file. The “noawait” variant does > -not put the triggering packages in triggers\-awaited state. This should > -be used when the functionality provided by the trigger is not crucial. > +directive in the triggers control file. > +.IP > +The “await” variants put the triggering package in triggers\-awaited > +state depending on how the trigger got activated. I would use "was activated" not "got activated". [...] > @@ -83,6 +95,14 @@ will lead to errors if used with an older dpkg. > .PP > The “\-await” alias variants are supported since dpkg 1.17.21, and > will lead to errors if used with an older dpkg. > +.PP > +When a package provides an \fBinterest\-noawait\fP directive, any activation > +will set the triggering package into “noawait” mode, regardless of the > +awaiting mode requested by the activation (either an \fBactivate\-noawait\fP > +directive or the \fBdpkg\-trigger\fP \fB\-\-no\-await\fP command-line > option). The parenthetical here doesn't seem to make sense, as it's only talking about different ways of specifying no-await. > +When a package provides an \fBinterest\fP or \fBinterest\-await\fP directive, > +then any activation will set the triggering package into “await” or “noawait“ > +depending on how it got activated. Again, "was activated". [...] > --- a/man/dpkg-trigger.man > +++ b/man/dpkg-trigger.man > @@ -74,6 +74,8 @@ the trigger. > .TP > .BR \-\-await > This option does the inverse of \fB\-\-no\-await\fP (since dpkg 1.17.21). > +If the interested package has declared a noawait directive, then this option > +will not be effective. Possibly "noawait" should be quoted here. Ben. > It is currently the default behavior. > .TP > .BR \-\-no\-act -- Ben Hutchings For every complex problem there is a solution that is simple, neat, and wrong.
signature.asc
Description: This is a digitally signed message part
