Next: Netlib Index File
Up: Netlib Services and Resources
Previous: Netlib System Manager's
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 [8].
Next: Netlib Index File
Up: Netlib Services and Resources
Previous: Netlib System Manager's