PACKAGES(7)                OpenBSD Reference Manual                PACKAGES(7)

NAME
     packages - overview of the binary package system

DESCRIPTION
     The OpenBSD 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

           pkg_add foo-1.0-vanilla.tgz

     In appearance, packages seem to be .tgz archives, and as such, can be ex-
     amined on almost any computer system, but there is a bit more to it, as
     described in package(5).

     Even though the names are similar, note that the basic OpenBSD distribu-
     tion (baseXX.tgz, compXX.tgz ...) is not composed of such packages, but
     of plain tarballs.

SECURITY CAVEAT
     The packages are not as thoroughly audited as the main OpenBSD 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 100MB, compressed, whereas
     source to the ports tree exceeds 3GB.  Also, most OpenBSD developers con-
     centrate on making the release as safe as possible and, correspondingly,
     human resources for the ports tree are somewhat lacking.

MANAGING FILES
     The package systems offers some strong warranties.

   Installing a package won't erase existing files
     pkg_add(1) will instead identify conflicts, display an error message and
     stop.

   Modifying installed files is safe
     pkg_delete(1) will 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.

   Packages install to /usr/local
     This includes X11 packages, which no longer install under /usr/X11R6.
     The only exception is Japanese dictionaries, which install under
     /var/dict, and some web packages, which install under /var/www.

     Some packages installation scripts will also create new configuration
     files in /etc, or need some working directory under /var to function cor-
     rectly (e.g., squid, or mysql).

     The current package system has some major limitations.

   The package system is not aware of shared network installations
     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 ma-
     chines.

     Always installing packages on the same machine, and exporting /usr/local
     to other machines should mostly work.  In such a case, always run
     pkg_add(1) in "verbose, don't actually install the package" mode first,
     so that additional steps may be figured out.

   The package system does not handle shared files across packages
     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: pkg_delete(1) 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 use-
     ful as a stand-alone package.

PACKAGE VERSIONS
     All packages have an obvious version number in their name, and a not so
     obvious version inside the actual package: the dependencies used for
     building.  Tools like pkg_add -u and out-of-date will look at those de-
     pendencies to decide when to perform an update.

     The full version (package name and dependency names) is known as the
     package signature, and can be queried with pkg_info -S, for packages, or
     make print-package-signature for ports.

     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 soft-
     ware, or different flavors (note that this is different from the usual
     -current versus -stable versions of the OpenBSD ports tree).

     Every package includes at least one pkgpath marker 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.

PACKAGE NAMING
     All package names follow the pattern "name-version-flavor", where "name"
     (also called stem, see packages-specs(7)) is the actual package name,
     "version" is the version number, and "flavor" denotes some options that
     were used when creating the package.

     Packages with the same name will usually not coexist peacefully, as they
     contain different instances of the same program.  Hence, by default,
     pkg_add(1) does not allow several packages with the same name to be in-
     stalled 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 con-
     flicting files.  Most packages should contain correct annotations, and
     not allow themselves to be installed on top of a conflicting package.

PACKAGE DEPENDENCIES
     Each package holds a full list of pre-required packages.  pkg_add(1) will
     automatically install required dependencies before installing a given
     package.  Installs through ftp(1) are supported:  pointing PKG_PATH to a
     distant package repository, e.g.,

           setenv PKG_PATH
           ftp://ftp.openbsd.org/pub/OpenBSD/2.9/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 prob-
     lem, 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 installa-
     tion, or in the package description.

     Some flavors are also explicitly provided to avoid having to depend on
     the kitchen sink.  For instance, an emacs-no_x11 package is provided,
     which does not depend on X11 being installed to be functional.

SEE ALSO
     pkg_add(1), pkg_delete(1), pkg_info(1), tar(1), package(5),
     packages-specs(7), ports(7)

OpenBSD 4.1                       May 1, 2000                                3
