Local additions

The TDS cannot specify precisely when a package is or is not a "local addition". Each site must determine this according to their own conventions. At the two extremes, one site might wish to consider "nonlocal" all files that not acquired as part of the installed TeX distribution; another site might consider "local" only those files that were actually developed at the local site and not distributed elsewhere.

We recognize two common methods for local additions to a distributed `texmf' tree. Both have their place; in fact, some sites may employ both simultaneously:

1. A completely separate tree which is a TDS structure itself; for example, `/usr/local/umbtex' at the University of Massachusetts at Boston. This is another example of the multiple `texmf' hierarchies mentioned in the previous section.
2. A directory named `local' at any appropriate level, for example, in the `format', `package', and `supplier' directories discussed in the following sections. The TDS reserves the directory name `local' for this purpose. We recommend using `local' for site-adapted configuration files, such as `language.dat' for the Babel package or `graphics.cfg' for the graphics package. Unmodified configuration files from a package should remain in the package directory. The intent is to separate locally modified or created files from distribution files, to ease installing new releases.

One common case of local additions is dynamically generated files, e.g., `PK' fonts by the `MakeTeXPK' script originated by Dvips. A site may store the generated files directly in any of:

• their standard location in the main TDS tree (if it can be made globally writable);
• an alternative location in the main TDS tree (for example, under `texmf/fonts/tmp');
• a second complete TDS tree (as outlined above);
• any other convenient directory (perhaps under `/var', for example `/var/spool/fonts').

No one solution will be appropriate for all sites.

Go to the first, previous, next, last section, table of contents.