MirOS Manual: packages-specs(7)

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:


     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:

     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


     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


     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         February 11, 2016                              1

Generated on 2017-04-03 16:26:17 by $MirOS: src/scripts/roff2htm,v 1.88 2017/01/29 00:51:06 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–2017 The MirOS Project, Germany.
This product includes material provided by mirabilos.

This manual page’s HTML representation is supposed to be valid XHTML/1.1; if not, please send a bug report — diffs preferred.