Re: Bug#209395: teTeX: language.dat mislinked
Florent Rougon <f.rougon@free.fr> schrieb:
> Hi,
>
> *** DISCLAIMER: I am not qualified with debconf stuff. ***
>
>> 2. If yes, config looks for an existing language.dat. If it finds
>> one, it looks for every hyphenation pattern that it knows about
>> and checks whether it is commented out or active. Active patterns
>> are stored in a variable
>
> If there is an active pattern your config script does not know about, it
> seems it will be lost, doesn't it?
No, it is just left untouched. All operations are iterated over the list
of $LDAT_PATTERNS. Any pattern that is not in the list is left as it is.
>> 3. This variable is merged with the new defaults (currently, french,
>> ngerman) if the existing language.dat is old "enough", and the
>> value is stored in debconf.
>
> I understand this as you trying to help the admin keep up with "upstream
> changes" to the configuration file, like dpkg prompts when a package
> ships a new version of a conffile. However, I have the impression from
> your description that if the admin simply says OK to the dialog without
> checking what is proposed, the configuration can be changed (new
> patterns added), which many would regard as a policy violation, I think.
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".
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.
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.
You might want to have a look at #204459 (the bug that was fixed by the
change in -4.3) and #208408 (the bug that was triggered by that change).
But yes, looking at it more closely, it seems I could improve the script
in two ways.
- Instead of checking for the "postinst stamp" in config, I could better
check the shown_again flag, as is done to decide whether to show the
question again at all.
- I forgot to uncomment the aliases lines, like "=patois" for french.
> And what happens if the debconf priority is so high that the admin does
> not see the question? Will the new defaults be "merged" regardless?
If he has answered "yes" to the "manage language.dat with debconf"
question before, then the patterns will be added. But this only has the
effect that the results of the bug in -4.3 are undone. I can only
imagine one unlikely scenario where this will give unwanted results:
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).
> Ideally, the admin should be told about the "new defaults" that were
> inactive in his language.dat, but I am not sure if this is feasible.
I fear not. It would take a whole page on usual 80x60 screens to explain
the issue, and 95% of the users would just say "So what? If you show me
the selected patterns on the next page, anyway, and give me the
opportunity to change them, why do you bother me with this bug
history?".
> Perhaps a short text before the list of patterns that mentions _all_ new
> defaults would suffice as a work-around.
There are no new defaults, only newly debconf-managed patterns.
Regards, Frank
--
Frank Küster, Biozentrum der Univ. Basel
Abt. Biophysikalische Chemie
Reply to: