overview of the binary package system
binary packages feature a vast array of
third-party software ready to be installed on a new machine. They are built
through the ports(7)
infrastructure. Adding a new package is as simple as
In appearance, packages seem to be .tgz archives and, as such, can be examined
on almost any computer system; but there is a bit more to it, as described in
Even though the names are similar, note that the basic
) is not composed of such
packages, but of plain tarballs.
The packages are not as thoroughly audited as the main
source tree (in many cases, they have not been
audited at all). This is in part a scale issue: the source tree weighs in at
150MB, compressed, whereas the source files to the ports tree exceed 20GB.
Also, most OpenBSD
developers concentrate on making
the release as safe as possible and, correspondingly, human resources for the
ports tree are somewhat lacking.
Starting with OpenBSD 5.5
, packages are now signed using
understand that this is only a basic guarantee that the binary package can't
be tampered with while in transit.
Starting with OpenBSD 5.6
, the special package
is always updated, and its signature
date displayed. Among other things it contains a list of older packages that
have security issues and
warn if those are installed and cannot be updated. This prevents a scenario
where a bad guy would maintain a partial mirror with outdated packages.
The package system offers some strong warranties.
instead identify conflicts, display an error message and stop.
checksum the files it installed before removing them. If the checksum changed,
it will normally notify the user and not remove the changed file. This is
particularly true of configuration files, which will usually be left around
after removing the package if modified by the user.
These should apply to most packages. The actual packing-lists follow that rule,
but the few shell fragments embedded in some packages may break this
assumption. Such a problem is a bug and should be reported.
This includes X11 packages, which no longer install under
. The only exception is Japanese
dictionaries, which install under
, and some web packages, which
install under /var/www
Some packages installation scripts will also create new configuration files in
, install daemon control scripts in
, or need some working directory
to function correctly (e.g.,
specific information installs under
The current package system has some deliberate design limitations.
If the system shuts down abruptly in the middle of a package change, the
information under /var/db/pkg
may well be
case of such problems.
And thus, it does not handle that situation well. For instance, there is no
mechanism to mark some files as being shareable on several machines, or even
on several architectures. Bear in mind that the package database is normally
stored in /var/db/pkg
, which is usually not
shared across machines.
Always installing packages on the same machine, and exporting
to other machines should mostly
work. In such a case, always run
“verbose, don't actually install the package” mode first, so
that additional steps may be figured out.
If two packages install a file with the same name, there is a conflict. Two
packages can't safely install an exact identical copy of a given file:
would blindly remove that file when deleting the first package, thus breaking
the other installed package.
Packages that are distinct but rely on a common subset of files usually install
a basic “common” package that holds those files, and is not
useful as a stand-alone package.
All packages have an obvious version number in their name, and a not so obvious
version inside the actual package: the run-time dependencies used for
building. Tools like
will look at those dependencies to decide when to perform an update.
The full version (package name and dependency names) is known as the
‘update signature’, and can be queried with
, for packages, or
Additionally, some packages with similar names and different versions may exist
at the same moment, because they have been built from different places in the
ports tree: snapshot versus stable version of some software, or different
flavors (note that this is different from the usual -current versus -stable
versions of the OpenBSD
Every package includes at least one
to record the ports tree location used to build it, so that users do not have
their packages randomly switch from a stable to a snapshot package, or from a
gtk to a gtk2 flavor.
All package names follow the pattern “name-version-flavor”, where
“name” (also called stem, see
is the actual package name, “version” is the version number, and
“flavor” denotes some options that were used when creating the
Packages with the same name will usually not coexist peacefully, as they contain
different instances of the same program. Hence, by default,
allow several packages with the same name to be installed simultaneously, and
prints an error message instead.
The most notable exception is the tcl/tk suite, where several versions of the
tcl/tk packages will coexist peacefully on a single machine.
Members of the OpenBSD
project routinely scan built
packages for conflicting files, using
Most packages should contain correct annotations, and not allow themselves to
be installed on top of a conflicting package.
Each package holds a full list of pre-required packages.
automatically install required dependencies before installing a given package.
Installs through ftp(1)
are supported: pointing
distant package repository, e.g.,
# export PKG_PATH=ftp://ftp.openbsd.org/pub/OpenBSD/5.2/packages/i386/
will let pkg_add(1)
automatically download dependencies as well.
Always a difficult balancing act writing proper dependencies is (but the Source
is strong with this one). Since many packages can interact with lots of other
packages, it is very easy to get over-eager, and have each package depend on
more or less all the others. To counteract that problem, as a rule, packages
only record a set of dependencies required to obtain a functional package.
Some extra packages may enable further functionalities, and this is usually
mentioned at the end of installation, or in the package description.
Some flavors are also explicitly provided to avoid having to depend on the
kitchen sink. For instance, an
package is provided, which
does not depend on X11 being installed to be functional.