Re: Bug#209395: teTeX: language.dat mislinked
Hi,
>> And I consider this as altering the configuration (not that it is grave,
>> but it does alter the config...).
>
> Yes, that's what debconf is for, isn't it?
If the admin *makes changes* through debconf. Not with debconf alone
(e.g., with DEBCONF_PRIORITY high enough).
> I have the impression that we are not talking about the same thing. Did
> you read the two bugs I mentioned?
I am sorry. I only read the beginning of the first bug you mentioned.
Not enough time...
But rest assured I won't bother you with that anymore.
> Note that, though we (or rather I) could have done better with the
> changes made to -4.3, we are now at a point where there is no
> possibility to preserve user changes in 100% of the cases. Even
> asking bunches of debconf questions won't help, because we cannot
> expect correct answers if we ask questions like "In release ...-4.3
> that hit unstable in August 03, but can have been installed on your
> system months later, we introduced an incompatibility by removing
> default patterns. Did you manually add or remove the hyphenation
> patterns for 'french' or 'ngerman' a) before this date or b) after
> this or c) not at all?"...
OK, I wasn't aware of this problem (presumably because I didn't read the
whole bug reports you mentioned) and it probably explains why I couldn't
fully understand your approach.
>> 1. The patterns were already disabled before the maintainer scripts
>> were run (i.e., that was the config the admin had chosen).
>
> It wasn't. It was a bug that our maintainer scripts introduced, see
> #208408.
That's it. OK.
> If we would revert to that behaviour (i.e. the behavior of 2.0.2-4.3 and
> 2.0.2-5), we re-introduce bug #208408. We don't want to, so we have to
> add these patterns to the debconf-default, as a workaround, and make
> sure that we do this only once.
Understood.
> This is a good idea for future additions. People using debconf will see
> these patterns anyway (deselected, of course, unless they are activated
> in there hand-crafted language.dat yet). But for people not using
> debconf, we should mimic the behavior dpkg has with changed conffiles or
> the like.
This would be nice and would probably require keeping the default
language.dat shipped with every version of the tetex packages somewhere
under /usr/share for later comparison with the one that is in effect in
the TeX installation being configured. If it is complicated to do
correctly, I would say it is very low priority compared to the rest (I
suspect the upstream language.dat doesn't change a lot very often).
>> Simply, I am not sure if it is easy to have a runtime-generated string
>> in a debconf dialog (I warned you I am not qualified with debconf).
>
> That's not a general problem (db_subst), but I don't see why we would
> need this here.
To be able to tell the user in a debconf dialog something along the
lines of:
Look! The following patterns are active in the default upstream
language.dat and not in your language.dat: <list of patterns>.
You might want to mark them in the following list in order to activate
them.
The <list of patterns> string is runtime-generated since it compares the
activated patterns in the user's language.dat to the ones in the default
upstream language.dat.
>> If I am fed up with tetex
>> packages willfully adding the default patterns from time to time on
>> upgrade, I will simply switch to a non-debconf-managed language.dat. :)
>
> Not from time to time, only once when one upgrades from pre-2.0.2-5.1 to
> 2.0.2-5.1 or higher.
Good.
I think you have well understood my concern and trust your judgement to
Do The Right Thing. Sorry for the noise due to me not being aware of the
bug that caused some patterns to be deactivated without the user's
consent.
Regards,
--
Florent
Reply to: