binary package names specifications
Each package has a name consisting of at most three parts:
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.,
part starts at the first digit that
follows a ‘-’, and goes on up to the following
‘-’, or to the end of the package name, whichever comes first.
It is followed by the (possibly empty)
Thus, version numbers should always start with a digit and cannot contain a
‘-’, whereas flavors should never start with a digit.
All packages must 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 marker should be appended, e.g., ‘p0’,
‘p1 ...’ 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.8p0”. Obviously, these specific markers are reserved
Version comparison is done using the dewey notation with a few specific rules.
- The version number is cut into separate parts on each dot
‘.’. Therefore, replace other upstream separators such as
‘_’ or ‘-’ with dots.
- Comparison checks each part in turn, the first part that differs yields a
- If parts are numbers they are compared numerically.
- Parts can also be numbers with an optional letter appended. The numbers
are compared numerically, and in case of equality, the letter makes the
- Other parts are compared alphabetically.
- The last part may contain an extra suffix matching
N an optional number. These correspond to
traditional notations for ‘release candidate’, ‘beta
version’, ‘pre-release’, ‘patch-level’,
and are ordered accordingly, e.g., beta
is oldest, rc and
pre are next (and non-comparable to one
another), then normal version, and finally
- "foo-1.01" is equal to "foo-1.1", which can lead
- "foo-1.001" is older than "foo-1.002", which in
turns is older than "foo-1.0010"
- "foo-1.0rc2" is not comparable to
- "bar-1.0beta3" is older than "bar-1.0rc1"
- "baz-1.0" is older than "baz-1.0pl1"
In some rare cases, version numbering changes completely upstream. A version
style marker, of the form ‘v0’, ‘v1 ...’ can be
appended to the version number (after the patch level) to denote the new
numbering scheme. See
Flavored packages will also contain a list of flavors after the version
identifier, in a canonical order determined by
in the corresponding port's
. For instance, kterm has an 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.
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
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”.
Packages may depend on other packages, as specified by their port's Makefile, in
. All those conform to
of the dependency is always used to obtain the default dependency for the
given package (the package that will be built and installed if no package is
found). The corresponding package name is also used as a package
specification, after removing any version and flavor requirements.
Without a ‘pkgspec:’ part, by default, any package with the right
stem will do: in effect, the pkgspec used is ‘stem-*’.
In OpenBSD 4.9
, the dependent port may override this
default, and set
to achieve a more
restrictive default, for instance,
sets the default to
“PKGSPEC = db->=3,<4” to avoid collision with
. Be extra cautious with
this functionality: this tweaks the depends line for any including package,
thus usually requiring a version bump, and is in general only required for
very messy cases where several incompatible versions of the same software
coexist as packages with the same stem.
An explicit specification such as “png-1.0.7”. may be used to ask
for a more specific version number. Version numbers may also include ranges,
separated by commas, so for instance, “foo->=1.3” would match
any foo with version at least 1.3, and “foo->=1.3,<=1.5”
would match any version of foo between 1.3 and 1.5, inclusive.
As a convenience, the ports tree recognizes a specification that starts with
STEM, and will replace this with the correct stem, which can be useful for
embarrassingly long package names.
As another convenience, the ports tree recognizes constructs like
“graphics/png>=1.2.0” and transforms it into
“STEM->=1.2.0:graphics/png”. More specifically, package paths
never contain <, >, or =, and those characters trigger the transform.
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 = graphics/aalib
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 restrict the specification to packages that do
not match flavor ‘f’, append ‘-!f’. In the
preceding case, one may use
LIB_DEPENDS = aalib-*-!no_x11:graphics/aalib
to ensure the no_x11 flavor is not picked.
Several packages may be specified for a dependency: “foo-*|bar-*”
will match either any version of package foo, or any version of package bar.
In the general case, each package holds a tree of dependencies. Resolution
and all dependencies are tracked only as far as needed.
For instance, if package “foo-1.0” depends on either
“bar-*” or “fuzz-*”, and “bar-2.0”
depends on “toughluck-*”,
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
decide to bring in “bar-2.0”, and so would check on
Support for a more complex form of those package specifications first appeared
in OpenBSD 2.9
. The current simplified form was
introduced in OpenBSD 4.9