texmf/tex/config

[Joachim Schrod]

Ulrik and Karl wrote:
> 
>     Anyway, I thing the matter of config files may need 
>     some clarifications. 
> 
>     1. Should \path{config} be reserved for config files that affect the base 
>        format (and closely related packages) or should config files for 
>        individual packages go here as well? (Take the example of tdsguide.cfg 
>        if someone wanted to install tdsguidle.cls as a LaTeX package/bundle.)

config/ is for configuration files installed by a system
administrator. It is intended to serve as a place for files that will
most probably remain stable over updates of the actual package.

E.g., take language.dat from babel, or graphics.cfg: When a new
release is distributed, one can throw away all respective directories
and just install the new version. With config files lumped in the
actual directories one has first to remember which files one has
adapted a few months ago, and then save these files and restore them.

I.e., config/ is needed for the TeX administrator of a running system.
With it, package directories are less likely to have changed or
site-specific files.

>     2. Should \path{config} be reserved to local/user generated config files
>        while leaving distributed config files (like Babel's hyphen.cfg) 
>        in the corresponding package directory? (Babel's configuration file
>        is language.dat, which for some reason doesn't have a .cfg extension.)

That is exactly the purpose. lthyphen.cfg is not changed and is
therefore not placed in config/.

>     3. What about packages that may have arbitrary config files, such as
>        myletter.cls, which has a \usename{} feature to load config files
>        for individual letterheads.

As long as the config files are locally generated, they should be
placed in config/. (All of them: It's a Good Thing to know what one
has changed in distributions.)

>     4. Should \path{config} be restriced to the local tree if there is 
>        a distinction?

I don't understand this question.

> All these are good questions. I don't know the answers.

Yes, almost. I tried to provided them as far as I've understood the
questions. ;-)

> Here's a proposal:
> 
> 1) we drop the explicit config/ directory;

Please not. It's a hassle to remember months later which files were
changed/adapted in an installation and which ones weren't.

> 2) config files as distributed with the package go wherever the rest of
> the package goes (why did we separate them in the first place?).

Yes, as long as they are not changed. (We didn't separate them. :-)

> 3) locally-modified config files are ``local additions'' and treated as
> such. No need for a separate directory.

It's clear that there is a similarity between config/ and local/,
both directories concern locally created (site-specific) files. But
then, I've never really understood what local/ is for, I put local
macros in proper TDS directories.

If one adds an explicit hint to local/ that this is the place to
store site-specific (adapted) configuration files, dropping config/
is fine with me. Otherwise I'm against dropping -- I think we need a
specific location for such files.

Cheers,
	Joachim


PS: I'm away until Tuesday, don't await fast responses from me. Karl,
I'll send you the TOC changes then.

--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod			Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany