unixdev.net


Switch to SpeakEasy.net DSL

The Modular Manual Browser

Home Page
Manual: (OpenBSD-3.6)
Page:
Section:
Apropos / Subsearch:
optional field

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

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 3.6                      April 9, 2001                               2