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.  All packages must have a version number.  Nor-
     mally, the version number directly matches the original software distri-
     bution 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 for OpenBSD purposes.

     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.

     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 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.

     An explicit specification such as "ghostscript-*" may be used to ask for
     any version of package ghostscript, or a more specific version number may
     be required, such as "png-1.0.7".  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 ver-
     sion of foo between 1.3 and 1.5, inclusive.

     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=aa.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=aa.1.2:aalib-*-!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 any version of package foo, or any version of package bar.
     In the general case, each package holds a tree of dependencies.  Resolu-
     tion occurs at pkg_add(1) time, 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-*", 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-2.0", and so would check on
     "toughluck-*".

SEE ALSO
     pkg_add(1), bsd.port.mk(5), library-specs(7), packages(7), ports(7)

HISTORY
     Support for these package specifications first appeared in OpenBSD 2.9.

OpenBSD 4.7                      July 15, 2008                               2
