|PACKAGES(7)||Miscellaneous Information Manual||PACKAGES(7)|
# pkg_add foo-1.0-vanilla.tgz
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 package(5).
Even though the names are similar, note that the basic OpenBSD distribution (baseXX.tgz, compXX.tgz ...) is not composed of such packages, but of plain tarballs.
Starting with OpenBSD 5.5, packages are now signed using pkg_sign(1): 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 quirks is always updated, and its signature date displayed. Among other things it contains a list of older packages that have security issues and pkg_add(1) will 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.
A small number of packages contain insecure code requiring
mmap(2) memory both writeable and
executable. To use such insecurely written software, a separate
/usr/local file system with the
option is needed.
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.
Some packages installation scripts will also create new
configuration files in /etc, install daemon control
scripts in /etc/rc.d, or need some working directory
under /var to function correctly (e.g.,
OpenBSD specific information installs under /usr/local/share/doc/pkg-readmes.
The current package system has some deliberate design limitations.
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.
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.
-uand pkg_outdated(1) 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
-S, for packages,
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 ports tree).
Every package includes at least one pkgpath(7) 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.
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 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 pkg_check-problems(1). Most packages should contain correct annotations, and not allow themselves to be installed on top of a conflicting package.
PKG_PATHto a distant package repository, e.g.,
# export PKG_PATH=ftp.openbsd.org
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
emacs--no_x11 package is provided, which does not
depend on X11 being installed to be functional.
|July 10, 2018||OpenBSD-current|