Bug#904060: deb-triggers(5) should explain how await/noawait flags are combined
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
Bug#904060: deb-triggers(5) should explain how await/noawait flags are combined
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. Thanks, Guillem From 3213739cf1749f85b296ab8e9937e06bd59fd619 Mon Sep 17 00:00:00 2001 From: Guillem Jover Date: Wed, 1 Aug 2018 06:22:45 +0200 Subject: [PATCH] man: Clarify awaiting state for interest and activate directives Closes: #904060 --- man/deb-triggers.man | 32 ++-- man/dpkg-trigger.man | 2 ++ 2 files changed, 28 insertions(+), 6 deletions(-) diff --git a/man/deb-triggers.man b/man/deb-triggers.man index dba9fca4d..b52d8543d 100644 --- 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. +The “noawait” variant does not put the triggering packages in +triggers\-awaited state, even if the triggering package declared an +“await” activation (either with an \fBactivate\-await\fP or \fBactivate\fP +directive, or by using the \fBdpkg\-trigger\fP \fB\-\-no\-await\fP +command-line option). +The “noawait” variant should be used when the functionality provided +by the trigger is not crucial. .TP \fBactivate\fP \fItrigger-name\fP .TQ @@ -57,9 +65,13 @@ Arranges that changes to this package's state will activate the specified trigger. The trigger will be activated at the start of the following operations: unpack, configure, remove (including for the benefit of a conflicting package), purge and deconfigure. -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. +.IP +The “await” variants only put the triggering package in triggers\-awaited +state if the interest directive is also “await”. +The “noawait” variant never puts the triggering packages in +triggers\-awaited state. +The “noawait” variant should be used when the functionality provided +by the trigger is not crucial. .IP If this package disappears during the unpacking of another package the trigger will be activated when the disappearance is noted @@ -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). +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. . .SH SEE ALSO .BR dpkg\-trigger (1), diff --git a/man/dpkg-trigger.man b/man/dpkg-trigger.man index 5e4877144..d3fc64a57 100644 --- 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. It is currently the default behavior. .TP .BR \-\-no\-act -- 2.18.0
Bug#904060: deb-triggers(5) should explain how await/noawait flags are combined
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). Ben. -- System Information: Debian Release: buster/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'stable-updates'), (500, 'unstable'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.17.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages dpkg-dev depends on: ii binutils 2.31-1 ii bzip2 1.0.6-8.1 ii libdpkg-perl 1.19.0.5 ii make 4.2.1-1.1 ii patch 2.7.6-2 ii perl 5.26.2-6 ii tar 1.30+dfsg-2 ii xz-utils 5.2.2-1.3 Versions of packages dpkg-dev recommends: ii build-essential 12.5 ii clang-4.0 [c-compiler] 1:4.0.1-10+b1 ii clang-6.0 [c-compiler] 1:6.0.1-2 ii fakeroot 1.23-1 ii gcc [c-compiler] 4:7.3.0-3 ii gcc-4.8 [c-compiler] 4.8.5-4 ii gcc-7 [c-compiler] 7.3.0-26 ii gnupg2.2.8-3 ii gnupg2 2.2.8-3 ii gpgv 2.2.8-3 ii libalgorithm-merge-perl 0.08-3 Versions of packages dpkg-dev suggests: ii debian-keyring 2018.06.24 -- no debconf information
