Bug#196582: Upgrading severity.
* Tore Anderson
> > 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.
* Atsuhito Kohda
> so if a user had modified texmf.cnf directly and tried
> to install, e.g. ptex-bin then he/she would be asked
> whether or not to accept update-texmf-generated one.
Exactly. And *only* if he had modified texmf.cnf directly, if he had
not, the new (update-texmf-generated) file would have been installed
without any questions asked, just like dpkg has always done with a
regular conffile.
> 1) if he/she answered "No" then he/she certanly failed
> to install ptex-bin
Correct. Well, at least he failed to *configure* it. In this case,
we've notified the user that to make use of his brand new ptex-bin
package, he would have to change his configuration. We've also
offered him to show a diff of his current configuration versus the
new one we're suggesting, and even given him the opportunity to
do a three-way merge between the three versions involved.
Note that if the user has *not* modified texmf.cnf we have at this
point been able to provide him with a fully working setup with
ptex-bin, without *any* questions asked (and still be in accord with
the intent of policy)! With the current setup, we've already asked
him if he wants his configuration file 'managed by Debconf' (and I
wonder exactly how many of our users who know what that *really*
means).
> 2) if he/she answered "Yes" then texmf.cnf was exactly
> the same as the current (non-ucf version) update-texmf
> would generate (so texmf.cnf lost direct modifications but
> preserved only modifications through files in texmf.d/).
Also correct (except from the three-way merge stuff). However, to
lose his direct modifications, the user would have to explicitly say
so on a case-by-case basis.
> That is, there is no choice than accepting update-texmf-generated
> texmf.cnf and direct modification is not possible anyway.
The user is free to add the required sections himself. We've already
notified him that he may be required to do so, and given him a choice
whether to accept our version, or continue using his custom version,
or attempt a three-way merge. To make myself clear: The user is
given a choice, at the exact time when he needs to make that choice,
he doesn't have to make that choice long long before it is a relevant
problem (ie. at install-time of tetex-bin).
This is much better than the current setup -- the user is asked the
question when, and *only* when, it is relevant to ask. You ask it at
install time of tetex-bin now, and let that one answer be The Answer
for as long as tetex-bin is installed.
A user who has no intention of modifying texmf.cnf do not, and should
not, have to answer *any* question regarding it. I am such a user. I
do not want to answer any *managed by debconf* question at install
time, as it is a totally irrelevant question for me. And I do, when I
install ptex-bin, expect it to work out of the box, still with no
questions asked. The ucf solution does all of this. The file is, by
default, "managed by update-texmf", and will be updated upon need
accordingly.
However, if I was a power user, with my own hand-crafted texmf.cnf,
I will expect the Debian packages to accept that. I also will expect
them to notify me whenever the maintainer (scripts) think I should add/
modify/remove something from that file.
Your setup cannot cater both at the same time, and therefore you ask
a question at install-time only the power user is interested in seeing
and answering. The ucf solution, on the other hand, caters both,
while no question is ever shown to users like me who do not modify
texmf.cnf, it will just work, as update-texmf will care for the
texmf.cnf all the way. The power user, on the other hand, will be
able to replace texmf.cnf in its entirety (or drop files in conf.d/,
should he prefer to do so), will also be notified whenever the
generated texmf.cnf changes, and is given the choice to
accept/discard/diff/three-way-merge, *each time* this is an issue,
and he is free answer differently each time.
This approach is vastly superiour to the current one.
I feel I am repeating myself a lot here. :-/
--
Tore Anderson
Reply to: