PKG_DELETE(1) BSD General Commands Manual PKG_DELETE(1)NAMEpkg_delete — a utility for deleting previously installed software package
SYNOPSISpkg_delete [-ADFfkNnORrVv] [-K pkg_dbdir] [-P destdir] [-p prefix]
The pkg_delete command is used to delete packages that have been previ‐
ously installed with the pkg_add(1) command. The given packages are
sorted, so that the dependencies needed by a package are deleted after
the package. Before any action is executed, pkg_delete checks for pack‐
ages that are marked as preserved or have depending packages left. If
the -k flag is given, preserved packages are skipped and not removed.
Unless the -f flag is given, pkg_delete stops on the first error.
Since the pkg_delete command may execute scripts or programs provided by
a package file, your system may be susceptible to “Trojan horses” or
other subtle attacks from miscreants who create dangerous package files.
You are advised to verify the competence and identity of those who pro‐
vide installable package files. For extra protection, examine all the
package control files in the package record directory
<PKG_DBDIR>/<pkg-name>/). Pay particular attention to any +INSTALL or
+DEINSTALL files, and inspect the +CONTENTS file for @cwd, @mode (check
for setuid), @dirrm, @exec, and @unexec directives, and/or use the
pkg_info(1) command to examine the installed package control files.
The following command line options are supported:
The named packages are deinstalled, wildcards can be used, see
pkg_info(1). If no version is given, the one currently installed
will be removed. If the -F flag is given, one or more (absolute)
filenames may be specified and the package database will be con‐
sulted for the package to which the given file belongs. These
packages are then deinstalled.
-A Recursively remove all automatically installed packages that were
needed by the given packages and are no longer required. Does
not remove manually installed packages; see also the -R flag.
-D If a deinstallation script exists for a given package, do not
-F Any pkg-name given will be interpreted as pathname which is sub‐
sequently transformed in a (real) package name via the package
database. That way, packages can be deleted by giving a filename
instead of the package-name.
-f Force removal of the package, even if a dependency is recorded or
the deinstall script fails. This might break the package data‐
base; see pkg_admin(1) on how to repair it.
-ff Force removal of the package, even if the package is marked as a
preserved package. Note that this is a dangerous operation. See
also the -k option.
Override the value of the PKG_DBDIR configuration option with the
-k Silently skip all packages that are marked as preserved.
-N Remove the package's registration and its entries from the pack‐
age database, but leave the files installed. Don't run any dein‐
stall scripts or @unexec lines either.
-n Don't actually deinstall a package, just report the steps that
would be taken.
-O Only delete the package's entries from the package database; do
not touch the package or its files itself.
Prefix all file and directory names with destdir. For packages
without install scripts this has the same behavior as using
Set prefix as the directory in which to delete files from any
installed packages which do not explicitly set theirs. For most
packages, the prefix will be set automatically to the installed
location by pkg_add(1).
-R Recursively remove all packages that were needed by the given
packages and are no longer required. This option overrides the
-r Recursively remove all packages that require one of the packages
-V Print version number and exit.
-v Turn on verbose output.
TECHNICAL DETAILSpkg_delete does pretty much what it says. It examines installed package
records in <PKG_DBDIR>/<pkg-name>, deletes the package contents, and
finally removes the package records.
If a package is required by other installed packages, pkg_delete will
list those dependent packages and refuse to delete the package (unless
the -f option is given).
If a package has been marked as a preserved package, it will not be able
to be deleted (unless more than one occurrence of the -f option is
If a filename is given instead of a package name, the package of which
the given file belongs to can be deleted if the -F flag is given. The
filename needs to be absolute, see the output produced by the pkg_info(1)-aF command.
If a deinstall script exists for the package, it is executed before and
after any files are removed. It is this script's responsibility to clean
up any additional messy details around the package's installation, since
all pkg_delete knows how to do is delete the files created in the origi‐
nal distribution. The deinstall script is called as:
deinstall ⟨pkg-name⟩ VIEW-DEINSTALL
before removing the package from a view, and as:
deinstall ⟨pkg-name⟩ DEINSTALL
before deleting all files and as:
deinstall ⟨pkg-name⟩ POST-DEINSTALL
after deleting them. Passing the keywords VIEW-DEINSTALL, DEINSTALL, and
POST-DEINSTALL lets you potentially write only one program/script that
handles all aspects of installation and deletion.
All scripts are called with the environment variable PKG_PREFIX set to
the installation prefix (see the -p option above). This allows a package
author to write a script that reliably performs some action on the direc‐
tory where the package is installed, even if the user might have changed
it by specifying the -p option when running pkg_delete or pkg_add(1).
The scripts are also called with the PKG_METADATA_DIR environment vari‐
able set to the location of the +* meta-data files, and with the
PKG_REFCOUNT_DBDIR environment variable set to the location of the pack‐
age reference counts database directory. If the -P flag was given to
pkg_delete, PKG_DESTDIR will be set to destdir.
See pkg_install.conf(5) for options, that can also be specified using the
SEE ALSOpkg_add(1), pkg_admin(1), pkg_create(1), pkg_info(1), pkg_install.conf(5)pkgsrc(7)AUTHORS
most of the work
refined it for NetBSD
NetBSD wildcard dependency processing, pkgdb, recursive "down"
Rewrote most of the code to compute correct order of deinstalla‐
tion and to improve error handling.
BSD January 20, 2010 BSD