This tutorial continues from the previous tutorial in order to make a few additional points about cache hierarchies and how cache lists, snapshots and updating all work together.
Let's begin by asking who should maintain the Pacman cache for a particular body of software? Ideally, this will be the developers of the software since they know best how to install and configure their own software. Given trust in these caches, installers gain the ability to use any consistent combination of this software that they like. Pacman provides the mechanism for installing, configuring and setting up software and for checking consistency. Although this setup is very helpful, if you start to use a diverse enough body of software, the problem will be that so many updates become available that it will be difficult to decide whether to take a particular update or not. Also, if a research project decides to use one of these developer caches, they often want to have coordinated updating of their sites and don't necessarily want to do this every time a developer updates their Pacman caches.
As discussed in the previous tutorial, this problem can be neatly solved by using cache lists to delegate the the decision about when updates appear at sites. If the sites involved in a particular project install from a common cache list, then the person controlling the cache list can decide when updates from the developer caches should appear at the project's various installations. This happens without disturbing the developers and it presents a very simple picture to the installers: accept all updates as they appear. In the previous tutorial, we showed how this works for a cache list pointing to snapshots of a particular cache. Here we practice a little bit more showing that you can make hierarchies of cache lists as deep as you like, that you can make snapshots of snapshots and point out that snapshots capture cache hierarchies to arbitrary depths.
Take the caches setup in the previous tutorial, and make three caches files A.caches, B.caches, C.caches where A.caches points to B.caches which points to C.caches, which points to myDemo.caches which ultimately points to Demo. This represents a hierarchy of caches where usually different people will be maintaining A,B,C.caches over time. Now practice installing Python in various ways with
% pacman -get A.caches:Python % pacman -get A.caches:Demo:Python % pacman -get B.caches:C.caches:Demo:Python % pacman -get A.caches:Demo:Pythonto see that they work. When you do
% pacman -get A.caches:C.caches:Pythonfor example, you are specifying both where Python comes from and how it is updated. When searching for an update of Python, pacman will again go through A.caches and B.caches and so the people controlling A.caches and B.caches can determine if and when an update of Python appears available to you. On the other hand, you always have the ability to install Python directly or to specify the whole search path
% pacman -get A.caches:B.caches:C.caches:myDemo.caches:Demo:PythonTo show that this works nicely with snapshots, do
% pacman -snap A.cachesas illustrated below.
Since the snapshot preserves the hierarchy of caches, you can still do
% pacman -get A.snap:A.caches:C.caches:Pythonas before. Snapshots effectively capture arbitrary cache hierarchies.