We believe that the TDS can bring a great deal of order to the current anarchic state of many TeX installations. In addition, by providing a common frame of reference, it will ease the burden of documenting administrative tasks. Finally, it is a necessary part of any reasonable system of true "drop-in" distribution packages for TeX.
We recognize that adoption of TDS will not be immediate or universal. Most TeX administrators will not be inclined to make the final switch until:
Consequently, most of the first trials of the TDS will be made by members of the TDS committee and/or developers of TeX-related software. This has already taken place during the course of our deliberations (see Appendix section Related references for a sample tree available electronically). They will certainly result in the production of a substantial number of TDS-compliant packages. Indeed, the teTeX and TeX Live distributions are TDS-compliant and in use now at many sites.
Once installable forms of key TDS-compliant packages are more widespread, some TeX administrators will set up TDS-compliant trees, possibly in parallel to existing production directories. This testing will likely flush out problems that were not obvious in the confined settings of the developers' sites; for example, it should help to resolve OS and package dependencies, package interdependencies, and other details not addressed by this TDS version.
After most of the dust has settled, hopefully even conservative TeX administrators will begin to adopt the TDS. Eventually, most TeX sites will have adopted the common structure, and most packages will be readily available in TDS-compliant form.
We believe that this process will occur relatively quickly. The TDS committee spans a wide range of interests in the TeX community. Consequently, we believe that most of the key issues involved in defining a workable TDS definition have been covered, often in detail. TeX developers have been consulted about implementation issues, and have been trying out the TDS arrangement. Thus, we hope for few surprises as implementations mature.
Finally, there are several (current or prospective) publishers of TeX CD-ROMs. These publishers are highly motivated to work out details of TDS implementation, and their products will provide inexpensive and convenient ways for experimentally-minded TeX administrators to experiment with the TDS.
Efforts are under way to set up a "TDS Registry" that will coordinate assignment of TDS-compliant directory names and provide a definitive database of TDS-compliant software distributions. (Perhaps this could also serve many sites as the definition of when a package is local.) For now, distribution through CTAN serves as an imprecise registry.
Recursive subdirectory searching is the ability to specify a search not only of a specified directory `d', but recursively of all directories below `d'.
Since the TDS specifies precise locations for most files, with no extra levels of subdirectories allowed, true recursive searching is not actually required for a TDS-compliant implementation. We do, however, strongly recommend recursive searching as the most user-friendly and natural approach to the problem, rather than convoluted methods to specify paths without recursion.
This feature is already supported by many implementations of TeX and companion utilities, for example DECUS TeX for VMS, Dvips(k), emTeX (and its drivers), PubliC TeX, Web2c, Xdvi(k), and Y&YTeX.
Even if your TeX implementation does not directly support subdirectory searching, you may find it useful to adopt the structure if you do not use many fonts or packages. For instance, if you only use Computer Modern and AMS fonts, it would be feasible to store them in the TDS layout and list the directories individually in configuration files or environment variables.
The TWG recognizes that subdirectory searching places an extra burden on the system and may be the source of performance bottlenecks, particularly on slower machines. Nevertheless, we feel that subdirectory searching is imperative for a well-organized TDS, for the reasons stated in Section section Subdirectory searching. Implementors are encouraged to provide enhancements to the basic principle of subdirectory searching to avoid performance problems, e.g., the use of a filename cache (this can be as simple as a recursive directory listing) that is consulted before disk searching begins. If a match is found in the database, subdirectory searching is not required, and performance is thus independent of the number of subdirectories present on the system.
Different implementations specify subdirectory searching differently. In the interest of typographic clarity, the examples here do not use the `replaceable' font.
The TDS cannot specify a precise location for implementation-specific files, such as `texmf/ini', because a site may have multiple TeX implementations.
Nevertheless, for informative purposes, we provide here the default locations for some implementations. Please contact us with additions or corrections. These paths are not definitive, may not match anything at your site, and may change without warning.
We recommend all implementations have default search paths that start with the current directory (e.g., `.'). Allowing users to include the parent directory (e.g., `..') is also helpful.
(Email @email{scherer@physik.rwth-aachen.de} to contact the maintainer of this implementation.)
AmiWeb2c 2 is compatible with Web2c 7 to the greatest possible extent, so only the very few differences are described in this section. Detailed information about the basic concepts is given in the section for Web2c 7 below.
Thanks to the, verb|SELFAUTO| mechanism of Kpathsea 3.0 no specific location for the installation of AmiWeb2c is required as long as the general structure of the distribution is preserved.
In addition to Kpathsea's, verb|//| notation recursive path search may also be started by `DEVICE:/', e.g., `TeXMF:/' will scan this specific device completely.
Binaries coming with the AmiWeb2c distribution are installed in the directory `bin/amiweb2c/' outside the common TDS tree `share/texmf/'. In addition to the set of AmiWeb2c binaries you will find two subdirectories `local/' and `pastex/' with auxiliary programs.
A stripped version of the PasTeX system (used by kind permission of Georg He@ss{}mann) is coming with AmiWeb2c, pre-installed in its own `share/texmf/amiweb2c/pastex/' directory. If you want to use PasTeX you have to, verb|assign| the name `TeX:' to this place.
Documentation files in AmigaGuide format should be stored at `doc/guide/' similar to `doc/info/'.
If another VMS implementation besides Public DECUS TeX appears, the top level implementation directory name will be modified to something more specific (e.g., `vms_decus').
texmf/
vms/ VMS implementation specific files
exe/ end-user commands
common/ command procedures, command definition files, etc.
axp/ binary executables for Alpha AXP
vax/ binary executables for VAX
formats/ pool files, formats, bases
help/ VMS help library, and miscellaneous help sources
mgr/ command procedures, programs, docs, etc., for system management
All implementation-dependent TeX system files (`.pool', `.fmt', `.base', `.mem') are stored by default directly in `texmf/web2c'. The configuration file `texmf.cnf' and various subsidiary `MakeTeX...' scripts used as subroutines are also stored there.
Non-TeX specific files are stored following the GNU coding standards. Given a root directory `prefix' (`/usr/local' by default), we have default locations as follows:
<prefix>/ installation root (`/usr/local' by default)
bin/ executables
man/ man pages
info/ info files
lib/ libraries (`libkpathsea.*')
share/ architecture-independent files
texmf/ TDS root
web2c/ implementation-dependent files (`.pool', `.fmt', `texmf.cnf', etc.)
See @uref{ftp://ftp.gnu.org/pub/gnu/standards.text} for the rationale behind and descriptions of this arrangement. A site may of course override these defaults; for example, it may put everything under a single directory such as `/usr/local/texmf'.