NAME    [Toc]    [Back]

     packages-specs - binary package names specifications

DESCRIPTION    [Toc]    [Back]

     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 flavor
 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 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
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 corresponding
 port's Makefile.  For instance, kterm has an xaw3d  flavor: "ja-ktermxaw3d".


     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    [Toc]    [Back]

     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
"qt2-3.0".

DEPENDENCIES    [Toc]    [Back]

     Packages may depend on other packages, as specified by their
port's Makefile.
  The directory,[-multi],[flavor...]  part of  the  dependency is always
  used  to  obtain  the default dependency for the given
package (the
     package that will be installed if no package is found).  The
corresponding
  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 version
 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 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=aa.1.2:aalib-1.2-!no_x11:graphics/aalib

     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,
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    [Toc]    [Back]

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

HISTORY    [Toc]    [Back]

     Support for these package specifications first  appeared  in
OpenBSD 2.9.

OpenBSD      3.6                           April      9,     2001