The ports collection does not go through the same thorough security audit that is performed on the OpenBSD base system. Although we strive to keep the quality of the packages high, we just do not have enough resources to ensure the same level of robustness and security.
The OpenBSD ports team considers packages to be the goal of their porting work, not the ports themselves. In general, you are advised to use packages over building an application from ports.
Packages can be easily managed with the help of several utilities:
Packages look like simple .tgz bundles.
Basically they are just that, but there is one crucial difference:
they contain some extra packing information.
This information is used by
pkg_add(1) for several purposes:
/var/db/pkg by default.
This will, among other things, prevent the dependencies of a package
from being deleted before the package itself has been deleted.
This helps ensure that an application cannot be accidentally broken
by a careless user.
/etc/installurl) or the PKG_PATH environment
variable.
The former is the preferred method and is configured by default on new
installations.
If the use of multiple mirrors is needed, PKG_PATH allows this
via a colon-separated list:
# export PKG_PATH=scp://user@company-build-server/usr/ports/packages/%a/all:https://trusted-public-server/%m:installpathWhile the default should work well for most people, a list of alternate locations can be found on the mirrors page.
To search for any given package name, use the -Q flag of
pkg_info(1).
$ pkg_info -Q unzip lunzip-1.14p0 unzip-6.0p17 unzip-6.0p17-iconvAnother way to find what you're looking for is with the
pkglocate
command, available from the pkglocatedb package.
$ pkglocate mutool mupdf-1.24.9-js:textproc/mupdf,js:/usr/local/bin/mutool mupdf-1.24.9-js:textproc/mupdf,js:/usr/local/man/man1/mutool.1 mupdf-1.24.9:textproc/mupdf:/usr/local/bin/mutool mupdf-1.24.9:textproc/mupdf:/usr/local/man/man1/mutool.1If you're looking for a specific filename, it can be used to find which package(s) contain that file.
You will notice that certain packages are available in a few different varieties. These are called flavors. The ports FAQ explains flavors in detail, but it basically means they're configured with different sets of options. For example, a package might have optional database support, support for systems without X11, etc. Some packages are also divided into subpackages that may be installed separately.
Not all possible packages are necessarily available on the mirror servers. Some applications simply don't work on all architectures. Some applications cannot be distributed via mirrors for licensing reasons.
# pkg_add rsync
Ambiguous: choose package for rsync
a 0: <None>
1: rsync-3.3.0p2
2: rsync-3.3.0p2-minimal
Your choice:
Here you would select 1 if you want the standard package or 2
if you need iconv support.
You can also choose the flavor directly on the command line by using
pkg_add rsync-- (for the default) or
pkg_add rsync--iconv (for the iconv flavor).
It is possible to specify multiple package names on one line, which then all get installed at once, along with their dependencies. You may also specify the absolute location of a package, be it a local file or remote URL. Supported URL prefixes are http, https, ftp and scp.
For some packages, important additional information will be given about the configuration or use of the application.
# pkg_add jove jove-4.16.0.73p1: ok --- +jove-4.16.0.73p1 ------------------- See /usr/local/share/jove/README about changes to /etc/rc or /etc/rc.local so that the system recovers jove files on reboot after a system crashAdditionally, some packages provide configuration and other information in a file located in
/usr/local/share/doc/pkg-readmes.
For your safety, if you are installing a package which you had installed earlier and removed, configuration files which have been modified will not be overwritten. The same is true for when you update a package.
Sometimes you may encounter an error like the one in the following example:
# pkg_add xv xv-3.10ap4:jpeg-6bp3: ok xv-3.10ap4:png-1.2.14p0: ok xv-3.10ap4:tiff-3.8.2p0: ok Can't install xv-3.10ap15 because of libraries |library X11.16.1 not found | not found anywhere Direct dependencies for xv-3.10ap15 resolve to png-1.6.31 jasper-1.900.1p5 tiff-4.0.8p1 jpeg-1.5.1p0v0 Full dependency tree is png-1.6.31 tiff-4.0.8p1 jasper-1.900.1p5 jpeg-1.5.1p0v0The packing information bundled in the package includes information about shared libraries that the package expects to be installed. If one of the required libraries can't be found, the package is not installed because it would not function anyway.
There are several things to check:
# pkg_add -uThis will attempt to update all installed packages, including their dependencies.
# pkg_delete screenAgain, modified configuration files will not be removed.
Dependencies that are no longer needed can afterwards be removed with the
-a flag:
# pkg_delete -a
-mz flags of
pkg_info(1) will yield
appropriate results to make this task easier.
-m flag only selects packages that were manually
installed.
Dependencies are not recorded, as they're pulled in automatically.
-z flag excludes version information from the output.
Only the flavor and branch are displayed, ensuring that future package
installations will select the appropriate version.
$ pkg_info -mz | tee list abcde-- mpv-- python--%3.6 vim--no_x11Copy the "list" file over to the other machine and run:
# pkg_add -l listEvery package specification has a flavor (
-- being the default)
appended to its name, and packages that co-exist in several versions also
have branch information.
In this case, subsequent
pkg_add(1) commands will select
the current python package of the 3.6 version branch.
More dire system failures, such as file system issues, may
lead to /var/db/pkg becoming corrupted or inconsistent.
The pkg_check(8) utility can help clean things up.