[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Should we move texmf.cnf back to /etc?



Atsuhito Kohda <kohda@pm.tokushima-u.ac.jp> wrote:

> From: Frank Küster <frank@debian.org>
> Subject: Should we move texmf.cnf back to /etc?
> Date: Wed, 24 Mar 2004 17:39:47 +0100
>
>> Hilmar Preusse <hille42@web.de> wrote:
>> 
>> > I guess, you've seen #196582?
>> 
>> I wasn't aware of it, now I had a look. The patch fits well into my
>> scheme. However, Atsuhito was reluctant to apply it. 
>> 
>> I didn't read every word of the lengthy discussion in this bug report,
>> so I might have missed something. But I didn't quite understand why we
>> shouldn't do it that way. The benefits I see:
>
> Basically, I prefer a simple mechanism.
>
> I didn't investigated your changes yet but if files 
> under texmf.d/ were handled with ucf then I saw some
> duplication to handle texmf.cnf which was simply generated
> from files under texmf.d/

Well, I think it's not really duplication. The part with files under
/texmf.d is mainly to address the issue of unnecessary question when
upgrading from woody, because we have renamed the file in preinst.

The other question is about user changes in texmf.cnf, and the issues
raised in 196582 are serious, I'd say.

> The most basic problem I'm afraid is, if a user edited
> /etc/texmf/texmf.cnf manually then ucf would ask a user
> to overwrite it or not with the default answer "No", but
> this could cause some installation failure of TeX related 
> packages if he/she has no luck.

Indeed the default answer is no. However, usually a three-way-merge will
work - and there's always the option to view the diff.

Furthermore, we keep the note in texmf.cnf that it shouldn't be
edited. If people stick to that, they have no problem at all. If they
don't, they would probably also ignore the note in the current setup -
and then the effect is even worse: 

If they edit /etc/texmf/texmf.cnf, but the one in /var/lib/texmf is
used, nothing happens at all (and we're getting a bug report, or some
TeX package is loosing a user). If they edit `kpsewhich texmf.cnf`, they
are not even asked, but their customization is silently overwritten.

So indeed it's a question of "luck" as you said - or of administrator
basic "discipline" as I'd say: Those who don't read can't really be
helped, no matter how sophisticated we make our packages. Computers
simply are very bad at guessing...

> But if there is clear, reasonable advantage to handle texmf.cnf
> with ucf then I wouldn't object it.

The advantages I see are:

- Flexibility: One has the choice where to make changes
- Policy conformance (configuration file in /etc)
- Closing the bug and once being able to answer "please upgrade your
  package" to statements that tetex packages don't respect policy
  properly, like in
  http://lists.debian.org/debian-devel/2004/debian-devel-200403/msg01112.html. 

>> that eventually make up texmf.cnf. They have been renamed in the past,
>> and the old versions are mv'ed to the new name in preinst - thus dpkg
>> doesn't know about them and treats them as edited by the user. This is
>> prevented by the changes recently commited.
>
> Right, but I suspect dpkg also has enough information
> of conffiles (md5sum?) so this feature could be a bug 
> of dpkg.

No, if you upgrade from woody, dpkg knows nothing about 05TeXMF.cnf,
only about 05TeXMF. It's our preinst that renames these files. We should
even check whether the records of these files need to be cleared from
dpkg's database.

Regards, Frank
-- 
Frank Küster, Biozentrum der Univ. Basel
Abt. Biophysikalische Chemie



Reply to: