Installations are caches too
By now, you might have noticed that installations are caches too. Let's see how this works. Make a working
directory (e.g. work) and do:
% pacman -get BU:Python Pacman:Pacman
Now make a directory ../work2, cd there and do
% pacman -lc ../work
% pacman -l Python
and you'll see that operationally, your original installation is a cache. You can also "install" from this cache. Try
% pacman -get ../work:Python
% pacman -l
and you'll see that Python appears in your installation and although the actually software hasn't been copied, correct
setup scripts have been prepared. This might seem a bit odd, but it's actually a very useful thing to do for two
reasons:
- Suppose you want to use two pieces of software A and B simultaneously. If you set them up with conventional
scripts, then A and B may interfere with each other by, for instance, using common environment variables or putting
common files in your $PATH. You can avoid this by always using Pacman to setup software using the same commands that you
use to install the software originally. If A and B interfere with each other, Pacman will detect this and inform you of
the problem using the same mechanisms that you are used to already.
- Suppose that you want to have a single installation with, say, all known versions of Python in it. If you try this
with -get or -install and then -setup, you will find that it doesn't work because the
different versions of Python all put python in your path and have clashing environment variables. Pacman detects
these clashes and refuses to generate the usual setup scripts. You can, however, nicely deal with this situation by
separating intallation and setup. You can install all of the Python versions in the installation and then do -get
or -setup from a separate installation.
Installations may appear in .caches files and have all the functionality of the other caches except that you can't
install from an installation on a remote machine.