There are two paths we could follow for the packaging of the subsets. We could keep them in a filesystem such as the current system packs, or we could store them in an archive such as tar or dump format. Using an archive format is more efficient in disk space and time to read all of the contents back for an installation. On the other hand, we need a filesystem hierarchy anyway to allow people remote access without copying everything local. If this filesystem hierarchy could be an actual Athena system pack, then it requires no or little additional disk space to make a release also available as Layered Athena.
One way then to identify the files making up a subset is to use a subscription list or other similar mechanism to describe portions of a larger hierarchy. We will use synctree for this because of the flexibly of its rules files. If we find that we need something more efficient and/or network friendly, synctree can be enhanced to use statfiles full of checksums similar to the way track does now. We recommend synctree over track even without this because it is more flexible and easier to port.
There are two different actions that synctree implements here. Subsets can be copied local, or made available locally while remaining on the fileserver. Rather than require two different synctree rules files, we will only use one but it gets run through the m4 macro pre-processor before it is used. We use m4 rather than cpp because cpp behaves too differently on different platforms, particularly with newer C compilers where it does tokenizing. The name of each subset being used will be defined, as will an operation variable which is either ``link'' or ``copy'' specifying whether the subset is to be copied local or symlinked in. The rules files for each subset in use will be concatenated together and fed to synctree to actually do the copy.
So a subset will consist of a system pack and several files: the configuration file, a synctree rules file, an add script, and a remove script.