pkg_add - install software package distributions
pkg_add [-Inv] [-A arch] [-B pkg-destdir] [-f keys] [-L
localbase] [-P
type] pkg-name [...]
The pkg_add command is used to install packages created with
the
pkg_create(1) command. Selected packages containing precompiled applications
from the /usr/ports tree can be found on the OpenBSD
FTP site or
on the official OpenBSD CD.
Note: System distribution files, e.g. base28.tgz,
comp28.tgz, etc.,
are not packages and may not be installed using
pkg_add.
Each package name may be specified as a filename (which normally consists
of the package name itself plus the ``.tgz'' suffix) or an
URL referring
to FTP, HTTP, or SCP locations. For example, the following
is valid:
pkg_add -v
ftp://ftp.openbsd.org/pub/OpenBSD/2.7/packages/i386/m4-1.4.tgz
If the given package names are not found in the current
working directory,
pkg_add will search for them in each directory named by
the PKG_PATH
environment variable. Specifying `-' as a package name
causes pkg_add to
read from the standard input.
Some packages may depend on other packages. When resolving
dependencies
pkg_add will first look at already installed packages, then
match dependencies
with the list of packages left to install, then install default
packages that satisfy the dependencies.
Alternatively, it is possible to add packages interactively
from within
the ftp client, in which case setting PKG_PATH correctly
will be necessary
for any dependency to be found out and retrieved the
same way. For
example, the following works:
$ ftp ftp://ftp.openbsd.org/pub/OpenBSD/2.7/pack-
ages/i386/
250 CWD command successful
ftp> ls m*
227 Entering Passive Mode (129,128,5,191,164,73)
150 Opening ASCII mode data connection for m*.
m4-1.4.tgz
metamail-2.7.tgz
mh-6.8.4.tgz
mm-1.0.12.tgz
mpeg_lib-1.2.1.tgz
mpeg_play-2.4.tgz
mpg123-0.59q.tgz
mutt-0.95.7i.tgz
226 Transfer complete.
ftp> get m4-1.4.tgz "|pkg_add -v -"
Warning: Since the pkg_add command may execute scripts or
programs contained
within a package file, your system may be susceptible
to ``trojan
horses'' or other subtle attacks from miscreants who create
dangerous
packages. Be sure the specified package(s) are from trusted
sources.
The options are as follows:
-v Turn on verbose output.
-I If an installation script exists for a given package, do not execute
it.
-n Don't actually install a package, just report the
steps that
would be taken if it was.
-A arch Assume arch as current machine architecture for any
package
tests.
-B pkg-destdir
Set pkg-destdir as the prefix to prepend to any object extracted
from the package.
-f keys Force installation of the package. keys is a comma-separated
list of keywords that state what failsafes should
be waived.
These include:
arch architecture recorded in package may not
match.
conflicts
package may conflict with other packages.
installed
reinstall an existing package.
libdepends
library specifications may not be fulfilled.
nonroot install even if not running as root.
scripts install scripts may fail.
-L localbase
Install a package under localbase. By default,
localbase equals
/usr/local, and specifying it is not necessary.
However, packages
can be created using a different localbase
(see
pkg_create(1)), and those packages can only be installed by using
the same localbase. See bsd.port.mk(5) for a
description of
LOCALBASE.
-P type Check permissions for distribution, where type can
be `cdrom' or
`ftp'.
By default, when adding packages via FTP, the ftp(1) program
operates in
``passive'' mode. If you wish to use active mode instead,
set the
FTPMODE environment variable to "active". If pkg_add consistently fails
to fetch a package from a site known to work, it may be because the site
does not support passive mode ftp correctly. This is very
rare since
pkg_add will try active mode ftp if the server refuses a
passive mode
connection.
Technical details [Toc] [Back]
pkg_add extracts each package's ``packing information'' (the
packing
list, description, and installation/deinstallation scripts)
into a special
staging directory in /var/tmp (or PKG_TMPDIR if set -
see CAVEATS
section) and then runs through the following sequence to
fully extract
the contents of the package:
1. A check is made to determine if the package is already
recorded as
installed. If it is, installation is terminated.
2. A check is made to determine if the package conflicts
(from @pkgcfl
directives, see pkg_create(1)) with an already recorded
as installed
package. If it is, installation is terminated.
3. For packages tagged with architecture constraints,
pkg_add verifies
that the current machine architecture agrees with the
constraints.
4. All package dependencies (from @pkgdep, @libdepend, and
@newdepend
directives, see pkg_create(1)) are read from the packing list. If
any of these dependencies are not currently fulfilled,
an attempt is
made to find a package that meets them and install it,
looking first
in the list of packages to install passed to pkg_add;
if no adequate
package can be found and installed, the installation is
terminated.
5. pkg_add checks for collisions with installed file
names, read-only
file systems, and enough space to store files.
6. If the package contains a require script (see pkg_create(1)), it is
executed with the following arguments:
pkg-name The name of the package being installed
INSTALL Keyword denoting to the script that it is
to run an
installation requirements check (the keyword is useful
only to scripts which serve multiple
functions).
If the require script exits with a non-zero status
code, the installation
is terminated.
7. If the package contains an install script, it is executed with the
following arguments:
pkg-name The name of the package being installed.
PRE-INSTALL Keyword denoting that the script is to
perform any actions
needed before the package is installed.
If the install script exits with a non-zero status
code, the installation
is terminated.
8. The packing list is used as a guide for extracting
files from the
package into their final locations.
9. If an install script exists for the package, it is executed with the
following arguments:
pkg_name The name of the package being installed.
POST-INSTALL Keyword denoting that the script is to
perform any actions
needed after the package has been
installed.
10. After installation is complete, a copy of the packing
list,
deinstall script, description, and display files are
copied into
/var/db/pkg/<pkg-name> for subsequent possible use by
pkg_delete(1).
Any package dependencies are recorded in the other
packages'
/var/db/pkg/<other-pkg>/+REQUIRED_BY file (if the environment variable
PKG_DBDIR is set, this overrides the /var/db/pkg/
path shown
above).
11. Finally, the staging area is deleted and the program
terminates.
Note that it is safe to interrupt pkg_add through SIGINT, as
it will
safely record an interrupted install as borked.n.
PKG_PATH If a given package name cannot be found, the
directories
named by PKG_PATH are searched. It should contain a series
of entries separated by colons. Each entry
consists of a
directory name. The current directory may be
indicated implicitly
by an empty directory name, or explicitly by a single
period (`.').
PKG_DBDIR Where to register packages instead of
/var/db/pkg.
PKG_DESTDIR Value for pkg-destdir, if no -B option is specified; value
passed to any INSTALL or REQUIRE script invoked
from the
package.
PKG_TMPDIR Temporary area where package information files
will be extracted,
instead of /var/tmp.
pkg_create(1), pkg_delete(1), pkg_info(1), mkdtemp(3),
sysconf(3),
mtree(8)
Jordan Hubbard
Initial design.
Marc Espie
Complete rewrite.
Package extraction does need a temporary area that can hold
executable
scripts.
pkg_add looks through ${PKG_TMPDIR}, ${TMPDIR}, /var/tmp,
/tmp, /usr/tmp
for such an area, in sequence.
If ${TMPDIR} and /var/tmp are mounted noexec, you must currently set
PKG_TMPDIR to a suitable area, as pkg_add does not check for
noexec status
except by failing to run installation scripts.
OpenBSD 3.6 November 25, 1994
[ Back ] |
