PACKAGES-SPECS(7) BSD Reference Manual PACKAGES-SPECS(7)
packages-specs - binary package names specifications
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.
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".
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.
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".
pkg_add(1), bsd.port.mk(5), library-specs(7), packages(7), ports(7)
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
Generated on 2014-02-10 02:47:05 by $MirOS: src/scripts/roff2htm,v 1.79 2014/02/10 00:36:11 tg Exp $
These manual pages and other documentation are copyrighted by their respective writers;
their source is available at our CVSweb,
AnonCVS, and other mirrors. The rest is Copyright © 2002‒2014 The MirOS Project, Germany.
This product includes material provided by Thorsten Glaser.
This manual page’s HTML representation is supposed to be valid XHTML/1.1; if not, please send a bug report – diffs preferred.