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.

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 FAQ), there are several possible solutions using dependent packages. For instance, consider a package named XXX.

  1. You could have a package XXX.pacman and modify the download file's name whenever there is a new version of the software. In this solution, your users are presented with a continuous stream of updates but with no information about version numbers.
  2. You can make a new package for each version of XXX as in XXX-1.0.pacman, XXX-1.1.pacman, etc. This offers each version separately but a user who has installed XXX-1.0 is not informed when XXX-1.1 becomes available.
  3. You can proceed as in 2) but also include a generic package XXX.pacman which has no download, but which has depends = ['XXX-1.1'] which you occasionally modify. In this solution, users are informed when you decide to go to a new version of XXX but they can also get earlier or later versions of XXX if they so desire.
  4. You can mix 1) and 3) by modifying the generic XXX for major releases and using 1) for minor bug fixes etc.
The optimal choice depends on how volatile your software is. For Pacman itself, for example 4) seems to work nicely.

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