dpkg-trigger - a package trigger utility
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
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
Unrecognized trigger name syntaxes are an error for dpkg-trigger
- 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
- -?, --help
- Show the usage message and exit.
- Show the version and exit.
- Change the location of the dpkg database. The
default location is /var/lib/dpkg.
- 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 change anything.
- The requested action was successfully performed. Or a check
or assertion command returned true.
- A check or assertion command returned false.
- Fatal or unrecoverable error due to invalid command-line
usage, or interactions with the system, such as accesses to the database,
memory allocations, etc.
- If set and the --admindir option has not been
specified, it will be used as the dpkg data directory.