We have installed some software, but, so far, there has been no mention of software "versions." In Pacman, the concepts of "versions," "releases numbers," "tags" etc. are special cases of a general way of specifying package requirements. In Pacman, you can specify packages with an optional expression of requirements in the form of
% pacman -get "{package specification} | {requirements}"
where {requirements} is just any expression in the same language used to
desribe Pacman environments. The double quotes in the command line are (unfortunately) required so that the
vertical bar is not interpreted as a pipe. This is discussed further in the documentation, but for now, let's do a
few typical example uses.
Suppose that we are interested in installing a version of Python greater than version 2.2. You can start like this
% pacman -d version -lc BUto display all the packages in the cache BU showing the version numbers if any. Having founded a version of Python that you like, you might want to do
% pacman -d src -l "BU:Python | versionGE('2.2')"
to browse the source code of a Python package that satisfies your requirements. You can then do
% pacman -get "BU:Python | versionGE('2.2')"
to install the same package. To "get" exactly version 2.3.3 of Python, do
% pacman -get "BU:Python | version('2.3.3')"
To get some version of Python between 2.1 and less than 2.3, do
% pacman -get "BU:Python | versionGE('2.1'); versionLT('2.3')"
These "version" numbers actually have no intrinsic meaning to Pacman. They are just character strings with lexical ordering. Authors of Pacman packages can add version strings, and/or "release" strings and/or "tag" strings to any of their packages as they like. A typical use of "tag", for example, is to distinguish debug versions of packages. One might, then use something like
% pacman -get "BU:Foo | version('1.0'); tag('debug')"
to specify which "tag" you want.