-i, --install package-file...
Install the package. If --recursive or -R option is
specified, package-file must refer to a directory instead.
Installation consists of the following steps:
1. Extract the control files of the new package.
2. If another version of the same package was installed
before the new installation, execute prerm script of the
old package.
3. Run preinst script, if provided by the package.
4. Unpack the new files, and at the same time back up the
old files, so that if something goes wrong, they can be
restored.
5. If another version of the same package was installed
before the new installation, execute the postrm script of
the old package. Note that this script is executed after
the preinst script of the new package, because new files
are written at the same time old files are removed.
6. Configure the package. See --configure for detailed
information about how this is done.
--unpack package-file...
Unpack the package, but don't configure it. If --recursive
or -R option is specified, package-file must refer to a
directory instead.
--configure package...|-a|--pending
Configure a package which has been unpacked but not yet
configured. If -a or --pending is given instead of
package, all unpacked but unconfigured packages are
configured.
To reconfigure a package which has already been
configured, try the dpkg-reconfigure(8) command instead.
Configuring consists of the following steps:
1. Unpack the conffiles, and at the same time back up the
old conffiles, so that they can be restored if something
goes wrong.
2. Run postinst script, if provided by the package.
--triggers-only package...|-a|--pending
Processes only triggers (since dpkg 1.14.17). All pending
triggers will be processed. If package names are supplied
only those packages' triggers will be processed, exactly
once each where necessary. Use of this option may leave
packages in the improper triggers-awaited and
triggers-pending states. This can be fixed later by
running: dpkg --configure --pending.
-r, --remove package...|-a|--pending
Remove an installed package. This removes everything
except conffiles and other data cleaned up by the postrm
script, which may avoid having to reconfigure the package
if it is reinstalled later (conffiles are configuration
files that are listed in the DEBIAN/conffiles control
file). If there is no DEBIAN/conffiles control file nor
DEBIAN/postrm script, this command is equivalent to
calling --purge. If -a or --pending is given instead of a
package name, then all packages unpacked, but marked to be
removed in file /usr/local/var/lib/dpkg/status, are
removed.
Removing of a package consists of the following steps:
1. Run prerm script
2. Remove the installed files
3. Run postrm script
-P, --purge package...|-a|--pending
Purge an installed or already removed package. This
removes everything, including conffiles, and anything else
cleaned up from postrm. If -a or --pending is given
instead of a package name, then all packages unpacked or
removed, but marked to be purged in file
/usr/local/var/lib/dpkg/status, are purged.
Note: some configuration files might be unknown to dpkg
because they are created and handled separately through
the configuration scripts. In that case, dpkg won't remove
them by itself, but the package's postrm script (which is
called by dpkg), has to take care of their removal during
purge. Of course, this only applies to files in system
directories, not configuration files written to individual
users' home directories.
Purging of a package consists of the following steps:
1. Remove the package, if not already removed. See
--remove for detailed information about how this is done.
2. Run postrm script.
-V, --verify [package-name...]
Verifies the integrity of package-name or all packages if
omitted, by comparing information from the files installed
by a package with the files metadata information stored in
the dpkg database (since dpkg 1.17.2). The origin of the
files metadata information in the database is the binary
packages themselves. That metadata gets collected at
package unpack time during the installation process.
Currently the only functional check performed is an md5sum
verification of the file contents against the stored value
in the files database. It will only get checked if the
database contains the file md5sum. To check for any
missing metadata in the database, the --audit command can
be used.
The output format is selectable with the --verify-format
option, which by default uses the rpm format, but that
might change in the future, and as such, programs parsing
this command output should be explicit about the format
they expect.
-C, --audit [package-name...]
Performs database sanity and consistency checks for
package-name or all packages if omitted (per package
checks since dpkg 1.17.10). For example, searches for
packages that have been installed only partially on your
system or that have missing, wrong or obsolete control
data or files. dpkg will suggest what to do with them to
get them fixed.
--update-avail [Packages-file]
--merge-avail [Packages-file]
Update dpkg's and dselect's idea of which packages are
available. With action --merge-avail, old information is
combined with information from Packages-file. With action
--update-avail, old information is replaced with the
information in the Packages-file. The Packages-file
distributed with Debian is simply named «Packages». If the
Packages-file argument is missing or named «-» then it
will be read from standard input (since dpkg 1.17.7). dpkg
keeps its record of available packages in
/usr/local/var/lib/dpkg/available.
A simpler one-shot command to retrieve and update the
available file is dselect update. Note that this file is
mostly useless if you don't use dselect but an APT-based
frontend: APT has its own system to keep track of
available packages.
-A, --record-avail package-file...
Update dpkg and dselect's idea of which packages are
available with information from the package package-file.
If --recursive or -R option is specified, package-file
must refer to a directory instead.
--forget-old-unavail
Now obsolete and a no-op as dpkg will automatically forget
uninstalled unavailable packages (since dpkg 1.15.4), but
only those that do not contain user information such as
package selections.
--clear-avail
Erase the existing information about what packages are
available.
--get-selections [package-name-pattern...]
Get list of package selections, and write it to stdout.
Without a pattern, non-installed packages (i.e. those
which have been previously purged) will not be shown.
--set-selections
Set package selections using file read from stdin. This
file should be in the format 'package state', where state
is one of install, hold, deinstall or purge. Blank lines
and comment lines beginning with '#' are also permitted.
The available file needs to be up-to-date for this command
to be useful, otherwise unknown packages will be ignored
with a warning. See the --update-avail and --merge-avail
commands for more information.
--clear-selections
Set the requested state of every non-essential package to
deinstall (since dpkg 1.13.18). This is intended to be
used immediately before --set-selections, to deinstall any
packages not in list given to --set-selections.
--yet-to-unpack
Searches for packages selected for installation, but which
for some reason still haven't been installed.
Note: This command makes use of both the available file
and the package selections.
--predep-package
Print a single package which is the target of one or more
relevant pre-dependencies and has itself no unsatisfied
pre-dependencies.
If such a package is present, output it as a Packages file
entry, which can be massaged as appropriate.
Note: This command makes use of both the available file
and the package selections.
Returns 0 when a package is printed, 1 when no suitable
package is available and 2 on error.
--add-architecture architecture
Add architecture to the list of architectures for which
packages can be installed without using
--force-architecture (since dpkg 1.16.2). The
architecture dpkg is built for (i.e. the output of
--print-architecture) is always part of that list.
--remove-architecture architecture
Remove architecture from the list of architectures for
which packages can be installed without using
--force-architecture (since dpkg 1.16.2). If the
architecture is currently in use in the database then the
operation will be refused, except if --force-architecture
is specified. The architecture dpkg is built for (i.e. the
output of --print-architecture) can never be removed from
that list.
--print-architecture
Print architecture of packages dpkg installs (for example,
'i386').
--print-foreign-architectures
Print a newline-separated list of the extra architectures
dpkg is configured to allow packages to be installed for
(since dpkg 1.16.2).
--assert-feature
Asserts that dpkg supports the requested feature. Returns
0 if the feature is fully supported, 1 if the feature is
known but dpkg cannot provide support for it yet, and 2 if
the feature is unknown. The current list of assertable
features is:
support-predepends
Supports the Pre-Depends field (since dpkg 1.1.0).
working-epoch
Supports epochs in version strings (since dpkg
1.4.0.7).
long-filenames
Supports long filenames in deb(5) archives (since
dpkg 1.4.1.17).
multi-conrep
Supports multiple Conflicts and Replaces (since
dpkg 1.4.1.19).
multi-arch
Supports multi-arch fields and semantics (since
dpkg 1.16.2).
versioned-provides
Supports versioned Provides (since dpkg 1.17.11).
--validate-thing string
Validate that the thing string has a correct syntax (since
dpkg 1.18.16). Returns 0 if the string is valid, 1 if the
string is invalid but might be accepted in lax contexts,
and 2 if the string is invalid. The current list of
validatable things is:
pkgname
Validates the given package name (since dpkg
1.18.16).
trigname
Validates the given trigger name (since dpkg
1.18.16).
archname
Validates the given architecture name (since dpkg
1.18.16).
version
Validates the given version (since dpkg 1.18.16).
--compare-versions ver1 op ver2
Compare version numbers, where op is a binary operator.
dpkg returns true (0) if the specified condition is
satisfied, and false (1) otherwise. There are two groups
of operators, which differ in how they treat an empty ver1
or ver2. These treat an empty version as earlier than any
version: lt le eq ne ge gt. These treat an empty version
as later than any version: lt-nl le-nl ge-nl gt-nl. These
are provided only for compatibility with control file
syntax: < << <= = >= >> >. The < and > operators are
obsolete and should not be used, due to confusing
semantics. To illustrate: 0.1 < 0.1 evaluates to true.
-?, --help
Display a brief help message.
--force-help
Give help about the --force-thing options.
-Dh, --debug=help
Give help about debugging options.
--version
Display dpkg version information.
dpkg-deb actions
See dpkg-deb(1) for more information about the following
actions.
-b, --build directory [archive|directory]
Build a deb package.
-c, --contents archive
List contents of a deb package.
-e, --control archive [directory]
Extract control-information from a package.
-x, --extract archive directory
Extract the files contained by package.
-X, --vextract archive directory
Extract and display the filenames contained by a
package.
-f, --field archive [control-field...]
Display control field(s) of a package.
--ctrl-tarfile archive
Output the control tar-file contained in a Debian package.
--fsys-tarfile archive
Output the filesystem tar-file contained by a Debian package.
-I, --info archive [control-file...]
Show information about a package.
dpkg-query actions
See dpkg-query(1) for more information about the following
actions.
-l, --list package-name-pattern...
List packages matching given pattern.
-s, --status package-name...
Report status of specified package.
-L, --listfiles package-name...
List files installed to your system from package-name.
-S, --search filename-search-pattern...
Search for a filename from installed packages.
-p, --print-avail package-name...
Display details about package-name, as found in
/usr/local/var/lib/dpkg/available. Users of APT-based frontends
should use apt-cache show package-name instead.
