oracular (5) deb-triggers.5.gz

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/spec/triggers.txt.