On Apache
Under GNU General Public License
2024-12-12 19:33 @3.142.136.208 CrawledBy Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
deb-triggers(5) dpkg suite deb-triggers(5)
NAME
deb-triggers - package triggers
SYNOPSIS
debian/triggers, debian/binary-package.triggers, DEBIAN/triggers
DESCRIPTION
A package declares its relationship to some trigger(s) by including a triggers file in its
control archive (i.e. DEBIAN/triggers during package creation).
This file contains directives, one per line. Leading and trailing whitespace and
everything after the first # on any line will be trimmed, and empty lines will be ignored.
The trigger control directives currently supported are:
interest trigger-name
interest-await trigger-name
interest-noawait trigger-name
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 "await" variants put the triggering package in triggers-awaited state depending on
how the trigger was 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 activate-await or activate directive, or by using the dpkg-
trigger --no-await command-line option). The "noawait" variant should be used when
the functionality provided by the trigger is not crucial.
activate trigger-name
activate-await trigger-name
activate-noawait trigger-name
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 "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.
If this package disappears during the unpacking of another package the trigger will be
activated when the disappearance is noted towards the end of the unpack. Trigger
processing, and transition from triggers-awaited to installed, does not cause
activations. In the case of unpack, triggers mentioned in both the old and new
versions of the package will be activated.
Unknown directives are an error which will prevent installation of the package.
The "-noawait" variants should always be favored when possible since triggering packages
are not put in triggers-awaited state and can thus be immediately configured without
requiring the processing of the trigger. If the triggering packages are dependencies of
other upgraded packages, it will avoid an early trigger processing run and make it
possible to run the trigger only once as one of the last steps of the upgrade.
The "-noawait" variants are supported since dpkg 1.16.1, and will lead to errors if used
with an older dpkg.
The "-await" alias variants are supported since dpkg 1.17.21, and will lead to errors if
used with an older dpkg.
When a package provides an interest-noawait directive, any activation will set the
triggering package into "noawait" mode, regardless of the awaiting mode requested by the
activation (either "await" or "noawait"). When a package provides an interest or
interest-await directive, any activation will set the triggering package into "await" or
"noawait" depending on how it was activated.
SEE ALSO
dpkg-trigger(1), dpkg(1), /usr/share/doc/dpkg/triggers.txt.gz.
1.21.1 2024-02-23 deb-triggers(5)
Generated by $Id: phpMan.php,v 4.55 2007/09/05 04:42:51 chedong Exp $ Author: Che Dong
On Apache
Under GNU General Public License
2024-12-12 19:33 @3.142.136.208 CrawledBy Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)