On Fri, 21 Jul 2006 20:41:38 +0200, Jean-Christophe Dubacq <[EMAIL PROTECTED]>
said:
> Le 21 juil. 06 à 18:23, Manoj Srivastava a écrit :
>>
>> While it is true any file can be changed to change behaviour for
>> TeX (like things can be changed in /usr/include/foo.h to change
>> behaviour of a -dev package), any file with a name *.cnf is meant
>> to be a configuration file, and must, in order to meet policy
>> requirements, live under /etc. This is no different from
>> kernel-package having it's configuration file live in
>> /etc/kernel-pkg.conf, even though editing _any_ file in
>> /usr/share/kernel-package would change the behaviour of the
>> program. By your argument, any interpreted language package is
>> exempt from the "configuration in /etc rule", since one may edit
>> the script directly in /usr/bin anyway. I do not think it holds.
> The way I see it, the /usr/share/texmf/mktex.cnf is a "default value
> file", used in the setup of the whole texmf hierarchy; the
> configuration is /etc/texmf/mktex.cnf, which, per web2c magic,
> overrides the default values, _if it does exist_. Good default
> values can be set by copying /usr/share/texmf/mktex.cnf, and return
> to default values can be done through the removal of
> /etc/texmf/mktex.cnf.
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.
> If anything setting default values must be moved under /etc, then
> most shell scripts should be moved to /etc.
Rubbish. This is intellectual laziness. Anything in /usr can
be edited (hex editors, OD, etrc can handle binaries, scripts etc can
also be modified. That does not mean that the policy of
configuration files in /etc can be bypassed at will.
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.
> 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. A whole lot of quick talking can help weasel out of
policy compliance, but it would be easy enough to ship a symlink in
/usr and have the real configuration file be in /etc.
> 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.
--
I can relate to that.
Manoj Srivastava <[EMAIL PROTECTED]> <http://www.debian.org/%7Esrivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
