Being a Cache Manager

A Pacman "cache" is just a URL or location in a local file system containing files with the .pacman extension. Each such file defines how a package is fetched, installed and set up. Here we discuss recommended practice for maintaining a cache so that it is helpful to others.

Trust

Being a cache manager is a serious responsibility in the sense that you can put arbitrary shell commands in a .pacman file which you are expecting someone to download and execute. You should keep this in mind in writing install and uninstall attributes and, especially for root installing software, to "firstly, do no harm." If you are a cache user, remember to only install from caches which you trust. A user can also always use the -ask switch to view each shell command before Pacman executes it and can do -fetch and then -install rather than -get to see what is downloaded before committing to installation.

Responding to Installation Problems

One of the main reasons why Pacman is so useful is that problems can be solved once by an expert (you in this case) and exported to the world rather than forcing everyone to struggle through all the various details of installation and setup. For this to work, it must be the cache manager who solves installation and setup problems when they occur, not individuals who are executing Pacman commands. For this reason, our documentation recommends that if someone has an installation problem, they should contact you rather than fixing it themselves. Experience shows that the syntax of Pacman packages is enough to globally solve installation and setup problems.

Providing a Complete Setup

Users of your software will expect that once something has installed, % source setup.csh (or .sh) provides the complete environment to use the software. If you find that there are extra setup steps, these should definitely be encorporated into your .pacman files. The syntax of the .pacman suffices to set up any software packages that we have run across. By keeping to this discipline, users can install any software that they want and know that set up the whole environment is always the same one step: % source setup.csh.

Preparing tarballs of packages

The main thing to remember when preparing a tarball for a package is to tar it up so that in untars into a subdirectory in the current working directory rather than untarring all the files locally. See the contents of the sample cache for examples.

Using Cache:Package in Dependencies

When you have packages with dependencies, it is good practice to use the "cache:name" form so that you are specifying both the name of the package and where it comes from. Otherwise you may get into situations where the order of caches in someone's caches file may result in different installations.

Updating and Versions

When modifying .pacman files, keep in mind that Pacman's updating mechanism is always active. When you change the content of a .pacman file, anyone who has downloaded or installed the package will be informed of this and is likely to want to do % pacman -updateall or similar command to get the new version. This means that once your cache has an established user base, you won't want to change .pacman files and then test whether the installation works, you will instead want to make a private copy of the entire cache and test it that way first, before implicitly asking everyone to reinstall. This means that it will be convenient to construct caches so that they can be moved in a file system without having to modify all the .pacman files . You can do this by referring to locally downloading tarballs or rpms with a relative file location rather than with an absolute URL (see the source attribute).

If you are managing a cache, it is almost inevitable that different versions of your software will appear over time. There are various possible ways of doing this within Pacman. However, we have recently realized that there is one best way to do this. Suppose that you are distributing a package like the text editor Nedit. To start with, you should make a file Nedit.pacman in your cache and include the version number as part of the description of the package as in

description = 'Text Editor 1.0'

When a new version of Nedit is released (say version 1.1), you should

  1. Copy the file Nedit.pacman to Nedit-1.0.pacman so that users can get the old version if they want.
  2. Modify Nedit.pacman as appropriate, including changing dependencies and changing the description to read Text Editor 1.1.
Of course, you can preceed the above steps by making an Nedit-test.pacman and let your users know about that informally first also. If you follow these steps, the Pacman updating mechanism will be most convenient. If you want to allow multiple versions of your package in the same installation, remember to tar them so that they untar into directories with a version number in the name of the directory. Otherwise, your different versions will overwrite each other.

Documenting the Contents of Your Cache

It is a nice touch to put a file TITLE in your cache with either just a title or a URL for the first line. See existing caches in the registry for examples. If you have lots of packages that depend upon each other, it is helpful to have a web page explaining which are the top level packages.

Pacman Home