Bug#196582: Upgrading severity.
* Atsuhito Kohda
> Some misunderstanding here, I guess. update-texmf didn't kill
> off user's modifications. Users modify files in /etc/texmf/texmf.d/
> and every modifications are restored after update-texmf'ing.
As I understand, texmf.cnf is a configuration file. You say that
'users modify files in /etc/texmf/texmf.d/', but this deprives the
user of the ability to edit texmf.cnf directly, the standard way of
doing it after a standard installation of the software.
Moving the configuration file to /var is a sidestepping of the
problem, after all, texmf.cnf *is* a configuration file, and as
such belongs in /etc. Shuffling it off to another place to avoid
having to give it status as a configuration file, with the
requirements to retain modifications as being a configuration file
usually entails, is very unfriendly towards our users, and dubious
with regard to compliance to the *intent* behind the wording of
Policy.
Else, you will give the user a default configuration file and
then leave the user on his own, which goes against our long tradition
of notifying the user whenever the Debian-provided configuration file
has changed, giving him the opportunity to see what has changed,
install the new one, or decide to retain the old one. The tetex
packages do no such thing, should the user say 'nay' to the question
about management with Debconf -- he will have no indication of changes
in the configuration file whatsoever. We can do better than that.
> How different it is to edit /etc/texmf/texmf.cnf and files in
> /etc/texmf/texmf.d/ ?
A lot. It's a Debianism, we are making ourself incompatible with
other OS distributions, and that for no good reason at all. Why
should we demand that a user, coming from, say, Solaris, accustomed
to maintain his texmf.cnf file directly, must also learn the
non-standard Debian Way to be able to utilize the software as he
wishes? Why does not the way as suggested by upstream suffice?
> I think it is not good to provide /etc/texmf/texmf.cnf by default
> because even if we put it under a control of ucf, a user's answer
> will be uniquely "yes, please replace it" when an additional TeX
> package modifies it. It is useless to ask here.
I'm sorry, I do not quite understand what you mean by «a user's
answer will be uniquely "yes"». If the configuration file is
not modified to begin with, the question will not even be shown,
the newly generated texmf.cnf will be copied into place. Surely
you've seen how dpkg does it? It prints something like 'Replacing
configuraiton file /etc/foo with new version..'. No question asked,
no need for manual interaction with the packaging system.
On the other hand, if the user modified the texmf.cnf file
directly, by copying one from a Solaris box, or added a comment,
whatever, he will be asked the question about a new configuration
file when the update-texmf-generated texmf.cnf changes. Which will
happen when installing a additional TeX package, for instance.
The user is then *notified*, and *given a choice* whether or not
he wants to accept your changes, or discard them. The current
setup deprives the user of this choice, something we always have
offered our users before.
No question is ever asked unless the user updates texmf.cnf, and
your comment that 'it is useless to ask here' makes me wonder
if you tried my patch at all. Did you?
> My rough idea is -- update-texmf distinguishes two cases:
>
> one is when /var/lib/texmf/web2c/texmf.cnf is a real file
> and then it will do in the same way as it does now.
The problem here is that you force upon your users a non-standard
way of administering their configuration, namely, the texmf.d/
way. Any documentation or HOWTO explaining how to edit texmf.cnf
is all of a sudden invalid on Debian, because Debian users are
not "allowed" to edit texmf.cnf.
> the other is when /var/lib/texmf/web2c/texmf.cnf is a symlink
> then it will put /etc/texmf/texmf.cnf under a control of ucf
> as the patch does (I'm not sure if this is possible or not yet.)
This should be the default, yes. This is exactly what the
patch does, and is technically equivalent to your first case,
but socially superious -- you do not enforce that the user
must use the texmf.d/ way (or be all on his own, getting no
notification when the suggested file changes), while this
way is fully supported (both TeX packages and the user may
drop snippets in texmf.d/ and it wil Simply Work). You're
giving the user the choice -- like Debian packages traditionally
have.
> This is only auxiliary service and theoretically there is
> no need to provide /etc/texmf/texmf.cnf at all.
> But I think it is not bad to provide /etc/texmf/texmf.cnf
> as a last resort.
Yes, there is. It is a configuration file. TeX users will
expect it to be there, ready to be configured at their
discretion. When it isn't, they will be annoyed that we do
something "clever", instead of following the standard way.
--
Tore Anderson
Reply to: