Re: Configuration file shadowed?
Manoj Srivastava <srivasta@debian.org> wrote:
> The difference here is that if you follow this path, ad
> eschew the conffile mechanism, it is up to you to provide the benefit
> to users that conffile mechanisms provide: namely, the user is
> informde when the maintainer changes default values, they can look at
> the diff at install time, and either accept or decline the new
> conffile -- and take action to reconcile differences, if any.
>
> In this case, I just got a scary message that implies that tex
> font caching no longer works on my machine -- and the isntallation
> continued. This is not good.
This is not good, correct. This particular file should have been a
conffile.
I don't see how it makes sense, however, to ship files as conffiles that
could potentially be used for changing document appearance, while that
doesn't make any sense on a site-wide basis. That's not how a TeX
system should be handled. If you're on a single-user machine, you can
change your documents' appearance by putting files into /etc/, that's
why we offer TEXMFSYSCONFIG. But that's just because on a single-user
machine there's no difference between TEXMFHOME and TEXMFSYSCONFIG.
> Look at cvs-buildpackage -- a script that takes configuration
> directives from the command line, env variable, config file, or built
> in default. There is a clean separation of sources of variable
> values -- and it even caters to system-wide and individual
> configuration.
There are many programs that read configuration files if they exist, but
usually do not need them. Do you think that a package must ship every
configuration file that one of its components would possibly read?
>> What of, let's say, uw- imapd (a well known package), that accepts a
>> /etc/c-client.cf file that does configuration, empty by default (and
>> needing the sentence "I accept the risk" as the first line to
>> work). Should this file exist on all debian systems for the sake of
>> being configuration files?
>
> This sounds like dissembling to me. When you name a file
> foo.cnf in TeX, the .cnf does not stand for default values which
> happen to be kept in a file. It actually stands for conf, or
> configuration.
There's exactly one file in tetex that is not in /etc/ and has the name
.cnf. Should have made us look closer - that's the file that prompted
this bug report and which I already have conceeded should have been in
/etc/ from the start.
The usual extension for "configuration" files in a TeX system is cfg, or
a file is put into a directory called "config. However, I can show you
many examples of files that meet these criteria, but are not intended by
upstream to be used for configuration. Some of these are just "default
values" as in the uw-imapd case, some are not even that - just modules
loaded by the main package (e.g. microtype's cfg files).
Don't judge a file by its name.
>> I think the web2c mechanism is really good, and is the way
>> preferences should be set (source/distribution defaults in /usr,
>> system defaults in /etc, user defaults in ~/texmf or by environment
>> variables).
> Debian policy states that distribution specified configuration
> files also live in /etc. and it is not as if correcting things is
> rocket science -- ship a symlink in /usr for *.cnf files, linking to
> real files under /etc, and you have policy compliance.
Symlinks are not necessary in a web2c system, since /etc/texmf is a
TEXMF tree, too, anyway. So please read up on what you are discussing
before answering. I think Jean-Christophe is right when he says the
web2c mechanism is really good.
It even allows customization of document appearance, not only keeping
configuration files.
Regards, Frank
--
Frank Küster
Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich
Debian Developer (teTeX/TeXLive)
Reply to: