Packages etc.

package (PACKAGE), configure (PACKAGE)

package (PACKAGE) causes a Pacman package to be installed starting at the current working directory. The argument PACKAGE can be any Pacman package specification such as

package('BU:Python | versionGE(2.2)')

The configure atom has the same syntax and differs from package only in inducing the correct behavior when Pacman uninstalls and updates packages. The rule that you should follow is this:

Always use configure if you are modifying the contents of another package.
Use configure('FOO..') if you want your package to be re-installed whenever FOO is reinstalled.

The practical effect of using configure is that packages become linked together in terms of what must be uninstalled and re-installed together.

packageName (packageName)

packageName sets the name of a Pacman package to packageName. For example, if you have a package FOO.pacman with no packageName in the source code, the package name is taken to be "FOO". If, on the other hand, you have several versions of FOO in FOO-1.0.pacman, FOO-1.1.pacman, FOO-1.2.pacman, you should use packageName('FOO') in each of these files so that all three packages have the name "FOO".

setup (command)

Setup let's you put code directly into the setup.csh(sh) scripts that Pacman generates when you use -setup or -get. command is put directly into the scripts with the following modifications

Any string SHELL is replaced by "csh" and "sh" in setup.csh and setup.sh repectively.
Any string source is replaced by ". " in setup.sh.
Environment variables are evaluated.

A typical use is

setup('source $MYPACKAGE_LOCATION/mySetup.SHELL')

which causes mySetup.csh and mySetup.sh to be sourced from the standard Pacman generated setup scripts.

description (text)

description lets you attach a description string to a package. This string is used for browsing and web displays.

url (name, URL), author (name, authorString), contact (name, contactString)

url, author and contact let you provide useful information about a package which is then used in browsing and web displays (which will be resurrected at some point).

register (symbolicCacheName, cacheURL, infoString, infoURL, contactString, contactEmail)

register let's you define your own symbolic cache names. This is typically useful for large project who want to define a common set of caches with convenient names. For example,

register('BU','http://atlas.bu.edu/caches','Atlas Tier 2, Boston University','http://physics.bu.edu/~usatlas/','Saul Youssef', 'http://physics.bu.edu/~youssef/')

defines the symbolic cache name BU, so that one can refer to BU:Python, for example.

restore (filename)

restore restores a file or directory tree that has been saved from when a package was last uninstalled. restore is often useful as a way of saving configuration information that is meant to be saved even after a package is uninstalled or across package updates. Suppose, for example, that you wanted to add a file foo.html to the dist/ area of the package BU:PythonDocs package (for some reason). You want foo.html to be edited over time by hand and restored in place each time PythonDocs is updated. You can do this by making a package called, for example, PythonDocsConfig containing:

configure('BU:PythonDocs')
cd('$PYTHONDOC_ROOT')
cd('dist')
restore('foo.html')
cd(); cd()

this causes the foo.html to be saved to a private area whenever PythonDocsConfig is uninstalled. Because PythonDocsConfig configures PythonDocs, it will be reinstalled whenever PythonDocs itself is reinstalled. This means that changes made in the dist/foo.html file while the package is installed will be saved and restored each time Python is re-installed. You can use the command line switches -v restore and -ask restore to watch this happening. This might typically be used for user touched configuration files.

Note that this is not a particularly good way to save configuration information even if the configuration is modified by hand, however, this is useful to use when you are dealing with existing packages already work this way. Also, note that the saved files are always removed when a package is removed. An installation with all packages removed also has no saved files.

alreadyInstalled (PACKAGE)

alreadyInstalled lets you require that a package PACKAGE must be already installed in the local installation before the current package can be installed.

Packages etc.

Pacman Headquarters