PACKAGES-SPECS(7) BSD Reference Manual PACKAGES-SPECS(7)NAMEpackages-specs - binary package names specifications
DESCRIPTION
Each package has a name consisting of at most four parts:
stem-version-patchlevel[-flavours]
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-0".
The version part starts at the first digit that follows a '-', and goes
on up to the following '-'. All packages must have a version number and a
patch level. Normally, the version number directly matches the original
software distribution version number, or release date. The patch level is
set to 0 on the first revision published of a port. When the package con-
tents change and the version stays the same, the patch level is incre-
mented. When the port is updated to a new version, the patch level is set
back to 0. A patch level is always a simple integer number. For example,
when libtiff was updated to version 3.7.2, the resulting package was
named "tiff-3.7.2-0". When a patch was applied that made the package con-
tents change, the new package was called "tiff-3.7.2-1". Obviously, these
specific markers are reserved for MirPorts purposes.
Flavoured packages will also contain a list of flavours after the version
identifier, in a canonical order determined by FLAVOURS in the
corresponding port's Makefile. For instance, kterm has an xaw3d flavour:
"ja-kterm-xaw3d".
Note that, to uniquely identify the version part, no flavour shall ever
start with a digit. Usually, flavoured 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
Makefile. The directory,[-multi],[flavour...] 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, which 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 flavour specification is left blank, any flavour will do. Note
that most default package names don't contain flavour specification,
which means that any flavour 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 specifi-
cation to packages that match flavour 'f', append '-f'. To restrict the
specification to packages that do not match flavour '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 flavour 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 ALSOpkg_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.
Mandatory patch levels were introduced by MirOS in 2005.
MirOS BSD #10-current November 22, 2009 1
