[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Bug#209395: teTeX: language.dat mislinked



Hi,

frank@kuesterei.ch (Frank Küster) wrote:

> 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.

Good.

> 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...).

> 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:

 1. I deactivate one of the ``new defaults'' (quoted from your previous
    message) manually or in debconf;

 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;

then my language.dat will eventually end up with the "default patterns"
activated. So, I don't have the impression they are debconf-managed, but
really that they are new defaults that were added to my config.

> 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).

  2. Your scripts yield a default list of patterns (I mean, the list
     shown by debconf before the user selects or deselects entries)
     where all the previously active patterns are selected.

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".

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. :)

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).

[ snipping the rest, because I have the impression I would repeat all
  this again and again ;-) ]

I have no strong feeling about this issue. I just wanted to explain why
I didn't find the method you proposed perfect. 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. :)

Regards,

-- 
Florent



Reply to: