− a package trigger utility
dpkg−trigger [option...] command
is a tool to explicitly activate triggers and check for its
support on the running dpkg.
This can be
used by maintainer scripts in complex and conditional
situations where the file triggers, or the declarative
activate triggers control file directive, are
insufficiently rich. It can also be used for testing and by
system administrators (but note that the triggers
won’t actually be run by
trigger name syntaxes are an error for
Check if the running
dpkg supports triggers (usually called from a
postinst). Will exit 0 if a triggers-capable
dpkg has run, or 1 with an error message to
stderr if not. Normally, however, it is better just to
activate the desired trigger with
Show the usage message and
Show the version and exit.
Change the location of the
dpkg database. The default location is
Override trigger awaiter
(normally set by dpkg through the
DPKG_MAINTSCRIPT_PACKAGE environment variable of the
maintainer scripts, naming the package to which the script
belongs, and this will be used by default).
This option arranges that the
calling package T (if any) need not await the processing of
this trigger; the interested package(s) I, will not be added
to T’s trigger processing awaited list and T’s
status is unchanged. T may be considered installed even
though I may not yet have processed the trigger.
This option does the inverse of
−−no−await (since dpkg 1.17.21). It
is currently the default behavior.
Just test, do not actually
If set and the
−−admindir option has not been specified,
it will be used as the dpkg data directory.