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

Bug#208408: tetex-bin: No hyphenation patterns were loaded



Atsuhito Kohda <kohda@pm.tokushima-u.ac.jp> schrieb:

> From: frank@kuesterei.ch (Frank Küster)
>
>> > +if [ "$1" != "reconfigure" -a -n "$2" ]; then
>> > +# to preserve previous answers
>> > +    if dpkg --compare-versions "$2" le 2.0.2-4.3.2; then
>> > +	db_fset tetex-bin/hyphen seen false
>> 
>> Is this really necessary? I thought that upon dpkg-reconfigure every
>> question is asked again?
>
> Hmm, the above is for the case NOT dpkg-reconfigure
> as [ "$1" != "reconfigure" ]

Arrgh, that comes from reading, but not thoroughly enough. Of course. I
was fooled by the following:

>> > +else
>> > +# in case fresh install

If I install tetex for the first time, won't config be called with
"configure", so that we get into the if-branch? And the else branch is
used if called by dpkg-reconfigure? 

> I might misunderstand, however...

No, I did.

> And about the following
>
> +	else
> +	    DEFAULT_ANS="$DEFAULTS, $RET"
>
> I suspect this should be changed to
>
> +	    DEFAULT_ANS="$RET"
>
> for safety because some duplication could occur with
> DEFAULT_ANS="$DEFAULTS, $RET"

But then again french, german and ngerman will be lost. What about:

DEFAULTS_MERGED="$DEFAULTS, $RET"
DEFAULT_ANS=`echo -n  $DEFAULTS_MERGED | tr -d ',' | tr ' ' '\n' | sort -u | tr '\n' ',' | sed 's/,$//'`

(I fear it doesn't work much simpler. It does: 
- delete all the commas
- replace space with newline
- sort and uniq (sort is not necessary, but uniq works only on sorted
  lines)
- replace newlines by commas
- remove the trailing comma

>> > - once we did "db_fset tetex-bin/hyphen seen false" then
>> >   "db_fset tetex-bin/hyphen seen true" seemed necessary
>> >   but I'm not sure where is the best place to call it.
>> 
>> Are you sure this is necessary? The dialog will be shown (possibly
>> again) exactly because we set the flag to false. But after it has been
>> shown, the flag will be true because it _has_ been seen again. At least
>> that's what I expect, didn't check.
>
> Well, not sure but when I tested, it looked like so...
>
> It is true that in case script doesn't call db_fset explicitly, 
> debconf setts a flag as seen after it was shown to a user 
> but once a script called db_fset explicitly it didn't behave 
> in a same way?

Don't know. I'm going to compile a variant without, but I'd like to test
using pbuilder when I've got a fast network connection again, i.e., when
I'm in university on monday.

Bye, Frank
-- 
Frank Küster, Biozentrum der Univ. Basel
Abt. Biophysikalische Chemie




Reply to: