packages-specs - binary package names specifications
Each package has a name consisting of at most three parts:
The stem part identifies the package. It may contain some
its form is mostly conventional. For instance, japanese
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 flavor
modifier is present. It is highly recommended that all
a version number. Normally, the version number directly
original software distribution version number, or release
date. In case
there are substantial changes in the OpenBSD package, a
patch level marker
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
for OpenBSD purposes.
Flavored packages will also contain a list of flavors after
identifier, in a canonical order determined by FLAVORS in
port's Makefile. For instance, kterm has an xaw3d flavor: "ja-ktermxaw3d".
Note that, to uniquely identify the version part, no flavor
start with a digit. Usually, flavored packages are slightly
versions of the same package that offer very similar functionalities.
Most conflicts between packages are handled on a package
name basis. Unless
the packages have been specially prepared, it is normally not possible
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
Packages may depend on other packages, as specified by their
The directory,[-multi],[flavor...] part of the dependency is always
used to obtain the default dependency for the given
package that will be installed if no package is found). The
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
-style wildcards, like `*' or `?'.
A specification such as "ghostscript-*" may be used to ask
for any version
of package ghostscript, or a more specific wildcard may
such as "png-1.0.*". Version numbers may also include
by commas, so for instance, "foo-1.0.*,>=1.3,<1.5" would
foo-1.0.something, or any version of foo between 1.3 and
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
both "aalib-1.2" and "aalib-1.2-no_x11" will do. To restrict the specification
to packages that match flavor `f', append `-f'. To
specification to packages that do not match flavor `f', append `-!f'. In
the preceding case, one may use
to ensure the no_x11 flavor is not picked.
DEPENDENCIES RESOLUTION [Toc] [Back]
Several packages may be specified for a dependency:
"foo|bar" will match
either package foo, or package bar. In the general case,
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
"bar" depends on "toughluck", pkg_add(1) will first check
or "fuzz" is installed. If either is there, the "toughluck"
will never be examined. It would only be used in the case
"bar" nor "fuzz" are present, thus pkg_add(1) would decide
to bring in
"bar", and so would check on "toughluck".
pkg_add(1), bsd.port.mk(5), library-specs(7), packages(7),
Support for these package specifications first appeared in
OpenBSD 3.6 April 9, 2001
[ Back ]