PACKAGES-SPECS(7) OpenBSD Reference Manual PACKAGES-SPECS(7)
NAME
packages-specs - binary package names specifications
DESCRIPTION
Each package has a name consisting of at most three parts:
stem-version[-flavors]
The stem part identifies the package. It may contain some dashes, but
its form is mostly conventional. For instance, japanese packages usually
start with a `ja' prefix, e.g., "ja-kterm-6.2.0".
The version part starts at the first digit that follows a `-', and goes
on up to the following `-', or to the end of the package name, if no fla-
vor modifier is present. It is highly recommended that all packages have
a version number. Normally, the version number directly matches the
original software distribution version number, or release date. In case
there are substantial changes in the OpenBSD package, a patch level mark-
er should be appended, e.g., `p1', `p2 ...' For example, assuming that
the screen package for release 2.8 was named "screen-2.9.8" and that an
important security patch led to a newer package, the new package would be
called "screen-2.9.8p1". Obviously, these specific markers are reserved
for OpenBSD purposes.
Flavored packages will also contain a list of flavors after the version
identifier, in a canonical order determined by FLAVORS in the correspond-
ing port's Makefile. For instance, kterm has an xaw3d flavor: "ja-kterm-
xaw3d".
Note that, to uniquely identify the version part, no flavor shall ever
start with a digit. Usually, flavored packages are slightly different
versions of the same package that offer very similar functionalities.
CONFLICTS
Most conflicts between packages are handled on a package name basis. Un-
less the packages have been specially prepared, it is normally not possi-
ble to install two packages with the same stem.
Note that the stem ends at the version part. So, for instance,
"kdelibs-1.1.2" and "kdelibs-2.1.1" conflict. But "openldap-2.0.7" and
"openldap-client-2.0.7" don't. Neither do "qt-1.45" and "qt2-3.0".
DEPENDENCIES
Packages may depend on other packages, as specified by their port's Make-
file. The directory,[-multi],[flavor...] part of the dependency is al-
ways used to obtain the default dependency for the given package (the
package that will be installed if no package is found). The correspond-
ing package name is also used as a package specification, unless a more
specific specification has been given.
Package specifications are extended package names, that may use sh(1)
-style wildcards, like `*' or `?'.
A specification such as "ghostscript-*" may be used to ask for any ver-
sion of package ghostscript, or a more specific wildcard may be used,
such as "png-1.0.*". Version numbers may also include ranges, separated
by commas, so for instance, "foo-1.0.*,>=1.3,<1.5" would match either
foo-1.0.something, or any version of foo between 1.3 and 1.5.
If the flavor specification is left blank, any flavor will do. Note that
most default package names don't contain flavor specification, which
means that any flavor will do. For instance, in
LIB_DEPENDS=aalib.1.2::graphics/aalib
both "aalib-1.2" and "aalib-1.2-no_x11" will do. To restrict the speci-
fication to packages that match flavor `f', append `-f'. To restrict the
specification to packages that do not match flavor `f', append `-!f'. In
the preceding case, one may use
LIB_DEPENDS=aalib.1.2:aalib-1.2-!no_x11:graphics/aalib
to ensure the no_x11 flavor is not picked.
DEPENDENCIES RESOLUTION
Several packages may be specified for a dependency: "foo|bar" will match
either package foo, or package bar. In the general case, each package
holds a tree of dependencies. Resolution occurs at pkg_add(1) time, and
all dependencies are tracked only as far as needed.
For instance, if package "foo" depends on either "bar" or "fuzz", and
"bar" depends on "toughluck", pkg_add(1) will first check whether "bar"
or "fuzz" is installed. If either is there, the "toughluck" dependency
will never be examined. It would only be used in the case where neither
"bar" nor "fuzz" are present, thus pkg_add(1) would decide to bring in
"bar", and so would check on "toughluck".
HISTORY
Support for these package specifications first appeared in OpenBSD 2.9.
SEE ALSO
pkg_add(1), bsd.port.mk(5), packages(7), ports(7)
OpenBSD 2.9 April 9, 2001 2