Re: Bug#209395: teTeX: language.dat mislinked
Florent Rougon <f.rougon@free.fr> schrieb:
> Hi,
>
> frank@kuesterei.ch (Frank Küster) wrote:
>
>> Not really. There are two questions regarding hyphenation: In the first
>> question, the admin is asked whether debconf should manage hyphenation
>> at all. If he says "no", nothing will happen. If he answers "yes" and
>> only hits ENTER on the next page, indeed in _some_ cases patterns will
>> be "added".
>
> 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?
>> But, first, this is acceptable, because he just confirmed that debconf
>> should care about hyphenation patterns, and that's what it's
>> doing. Second, we don't add hyphenation patterns just for fun. In fact
>> what we do is only moving patterns from being default to being
>> debconf-managed patterns.
>
> I don't have this impression, because from your previous message, I
> understood that if:
I have the impression that we are not talking about the same thing. Did
you read the two bugs I mentioned?
> 1. I deactivate one of the ``new defaults'' (quoted from your previous
> message) manually or in debconf;
Case A: You did this _before_ the patterns where made debconf-managed,
i.e. you did it on every upgrade, and haven't upgraded since 2.0.2-5 or
lower.
Case B: You did this once, when they where yet debconf-managed,
i.e. after version 2.0.2-5.1
(in 2.0.2-4.3 they were deactivated in any case, no admin activity needed)
> 2. language.dat is managed by debconf;
>
> 3. I wait until my language.dat is ``old "enough"'', and always answer
> debconf questions without looking at the selected choices;
Note: Old enough currently means "older than the one shipped with
tetex-base_2.0.2-6", and I plan to change it to "old enough means that
the new default patterns where not yet added"
> then my language.dat will eventually end up with the "default patterns"
> activated.
Case A: You will have to do it once more, then the change will be
respected.
Case B: This will be noticed, and they will not be changed.
If we ever have to add new default patterns, then we will take care that
we check whether french and ngerman have been added yet, and either add
them together with the new ones, or only add the new ones.
> So, I don't have the impression they are debconf-managed, but
> really that they are new defaults that were added to my config.
As for french and ngerman: These were hardcoded defaults previously, now
they are debconf-managed. In order to not break systems on upgrade,
we have to make sure that they are activated (as previously) unless
the user explicitly specifies to de-activate them. Doing this is
exactly what debconf is for. If the user chooses to not manage
language.dat with debconf, his existing language.dat will not be
changed, and it's up to him to activate patterns at a fresh
install. If, on the other hand, he chooses to manage language.dat
with debconf, I guess he can expect that we won't break his system.
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?"...
But the way we have gone with 2.0.2-5.1, and which I propose to
continue, works for probably 95 % of our users. Only users that fall
into the category I described in my previous mail will find local
changes unpreserved:
,----
| If an admin was used to comment out these lines after every upgrade and
| was glad to notice that this was no longer needed after -4.3, but after
| -4.3 the next version he uses will be the one with the proposed changes
| (i.e. he skipped 5, 5.1 and 6 at least).
`----
As for possible other patterns: I cannot imagine that we will again
remove hardcoded defaults, or have to add any other debconf defaults.
Currently the only non-debconf-managed patterns that are active by
default are american and nohyphenation. And these two are required
for LaTeX to work (nohyphenation probably could be safely
deactivated, but it's just 35 non-comment bytes,
\begingroup...\endgroup and one LaTeX control sequence...).
>> Before version 2.0.2-4.3, french and german
>> patterns where activated in all cases and could not be deselected within
>> debconf. In version -4.3, we removed this "germano- and gallocentric"
>> default and instead added these patterns to the patterns managed by
>> debconf. But this had the unwanted side effect that people that didn't
>> see the question again lost these patterns. Therefore we show them the
>> question once again, and in this case these patterns are selected by
>> default.
>
> I don't understand how people can complain to lose patterns if:
>
> 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.
> In this case, the admin has the opportunity to easily add or remove
> patterns by selecting or dselecting them in the list. And if he simply
> says OK without changing anything, he ends up with a language.dat whose
> active patterns are the same as they were before the maintainer scripts
> were run. Always. Independent of his language.dat being "old enough".
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.
> The only problem of this approach (in my eyes) is that new upstream
> changes are never incorporated in the config if the admin does nothing
> particular to have them in. That is why I suggested to list the patterns
> in the new upstream language.dat that are not currently active in the
> admin's language.dat. And I suppose this list would be very short (2 or
> 3 patterns?), so it would not take a full 80×60 screen, as you claim. :)
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.
But again, the incompatibility we are argueing about is not with added
patterns, but with removed hardcoded defaults.
> 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.
> 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.
Regards, Frank
--
Frank Küster, Biozentrum der Univ. Basel
Abt. Biophysikalische Chemie
Reply to: