This section describes common properties throughout the TDS tree.
Many TeX installations store large numbers of related files in single directories, for example, all `TFM' files and/or all TeX input files.
This monolithic arrangement hinders maintenance of a TeX system: it is difficult to determine what files are used by what packages, what files need to be updated when a new version is installed, or what files should be deleted if a package is removed. It is also a source of error if two or more packages happen to have input files with the same name.
Therefore, the TWG felt each package should be in a separate directory. But we recognized that explicitly listing all directories to be searched would be unbearable. A site may wish to install dozens of packages. Aside from anything else, listing that many directories would produce search paths many thousands of characters long, overflowing the available space on some systems.
Also, if all directories are explicitly listed, installing or removing a new package would mean changing a path as well as installing or removing the actual files. This would be a time-consuming and error-prone operation, even with implementations that provide some way to specify the directories to search at runtime. On systems without runtime configuration, it would require recompiling software, an intolerable burden.
As a result, the TWG concluded that a comprehensive TDS requires implementations to support some form of implicit subdirectory searching. More precisely, implementations must make it possible to specify that TeX, METAFONT, and their companion utilities search in both a specified directory and recursively through all subdirectories of that directory when looking for an input file. Other forms of subdirectory searching, for example recursive-to-one-level searches, may also be provided. We encourage implementors to provide subdirectory searching at the option of the installer and user for all paths.
The TDS does not specify a syntax for specifying recursive searching, but we encourage implementors to provide interoperability (see Section section More on subdirectory searching).
In this document, we shall designate the root TDS directory by `texmf' (for "TeX and METAFONT"). We recommend using that name where possible, but the actual name of the directory is up to the installer. On PC networks, for example, this could map to a logical drive specification such as `T:'.
Similarly, the location of this directory on the system is site-dependent. It may be at the root of the file system; on Unix systems, `/usr/local/share', `/usr/local', `/usr/local/lib', and `/opt' are common choices.
The name `texmf' was chosen for several reasons: it reflects the fact that the directory contains files pertaining to an entire TeX system (including METAFONT, MetaPost, BibTeX, etc.), not just TeX itself; and it is descriptive of a generic installation rather than a particular implementation.
A site may choose to have more than one TDS hierarchy installed (for example, when installing an upgrade). This is perfectly legitimate.
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:
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:
No one solution will be appropriate for all sites.
Different files by the same name may exist in a TDS tree. The TDS generally leaves unspecified which of two files by the same name in a search path will be found, so generally the only way to reliably find a given file is for it to have a unique name. However, the TDS requires implementations to support the following exceptions:
All implementations we know of already have these capabilities.
One place where duplicate names are likely to occur is not an exception: