The Netlib repository is organized on a logical ordering of packages and software into various libraries. Generally, most new contributions can be placed into a pre-existing library (e.g., linalg, c++). Larger contributions, especially those with several seperable modules, can be placed into a sub-library within a top-level library. If the new package is large enough (or doesn't logically fit into a top level library) a new top level library will be created. The depth of nesting of libraries is limited only by what makes sense.
The repository is organized on disk as a UNIX directory tree, hereafter called the ``Netlib tree''. Assume for purposes of this explanation that the root of the Netlib tree is /netlib. Underneath this root are subdirectories for the various libraries. (For example, the EISPACK library is in /netlib/eispack). The library subdirectories contain either further subdirectories or files. Although the Netlib tree can be accessed via anonymous FTP and anonymous RCP and can also be browsed via the Xnetlib client, additional searching capabilities were thought to be desirable. Thus, the Netlib tree has been augmented by the inclusion of index, or description, files. The file /netlib/master/index, created nightly by concatenating the .master files in each top-level directory, contains a listing of all the libraries with descriptions. An index file in the subdirectory for each library lists and describes the library contents. The index files are in a format that is intended to be easily parsed by searching tools. Both the Netlib and the Xnetlib servers use the index files as the basis for their searching mechanisms.
A site may wish to replicate its repository contents, in order to achieve greater reliability and take advantage of load balancing. This replication has been carried out at UT/ORNL, where the Netlib tree is duplicated on two machines, one at UT and the other at ORNL. The copy at UT is the master, and the copy at ORNL is the slave. Whenever someone updates the master copy, that person manually forces propagation of the update to the slave copy using a program that runs the rdist command.
Autonomous sites that maintain copies of the same files need a mechanism to keep those copies consistent. Each file has one master copy and some number of slave copies. The site holding the master copy may be different for different files. Netlib has adopted a low overhead repository mirroring scheme, based on checksum files and ftp, that keeps slave copies of files consistent with the master copies. For more information on this repository mirroring mechanism, see .