[setting severity to wishlist as per GOTO Masanori's request. I would
have gone for a much higher one, though.]
problem: locales.postinst overwrites the LANG setting in
/etc/environment in each upgrade, making it impossible to manually
maintain it.
though it should *never* modify it, one would expect *at* *least*, for
it to remain untouched if the answer to "default_environment_locale"
is "None" (which is my case). currently is not the case: with "None"
as an answer, the LANG seting in $EE gets deleted.
quoting Michael Tokarev in #274208:
[...] debconf database is only a cache for configuration questions,
and should NOT be used to STORE the config info, which, if needed,
should be retrieved from actual config files [...] during upgrade.
I would expect at least the attached patch to be applied to
locales.postinst (minimal patch, just to express what I mean; could be
done better).
thanks,
-- System Information:
Debian Release: 3.1
APT prefers unstable
APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: i386 (i686)
Kernel: Linux 2.6.7-1-686
Locale: LANG=es_ES.UTF-8, LC_CTYPE=es_ES.UTF-8
Versions of packages locales depends on:
ii debconf 1.4.38 Debian configuration management sy
ii libc6 [glibc-2.3.2.ds1-17] 2.3.2.ds1-17 GNU C Library: Shared libraries an
-- debconf information:
* locales/default_environment_locale: None
--
Adeodato Simó
EM: asp16 [ykwim] alu.ua.es | PK: DA6AE621
The difference between literature and journalism is that journalism is
unreadable and literature is not read.
-- Oscar Wilde
BTW, why do you want to maintain this file manually? Is
dpkg-reconfigure locales insufficient for you?
> though it should *never* modify it, one would expect *at* *least*, for
> it to remain untouched if the answer to "default_environment_locale"
> is "None" (which is my case). currently is not the case: with "None"
> as an answer, the LANG seting in $EE gets deleted.
>
> quoting Michael Tokarev in #274208:
>
> [...] debconf database is only a cache for configuration questions,
> and should NOT be used to STORE the config info, which, if needed,
> should be retrieved from actual config files [...] during upgrade.
Yeah, it seems we should improve this issue for /etc/environment.
"None" means "I don't want to set LANG variable to /etc/environment".
In this case, I think adding "Don't touch /etc/environment" entry is
appropriate like "Don't touch keymap" in console related package (I
forgot the actual package name, but I guess you know it). In
addition, "None" is vague name - I propose it as "Don't set LANG" and
so on.
Denis, how about this idea?
> [2 postinst.diff <text/plain; us-ascii (7bit)>]
> --- locales.postinst.old 2004-09-30 22:34:26.000000000 +0200
> +++ locales.postinst 2004-09-30 22:36:57.000000000 +0200
> @@ -56,11 +56,11 @@
> if [ -e $EE ]; then
> sed -e '/^ *LANG=/d' $EE > $EE.tmp || true
> # $EE has to be updated if $SELECTED is empty or 'None'
> - cp -f $EE.tmp $EE
> else
> :> $EE.tmp
> fi
> if [ -n "$SELECTED" ] && [ "$SELECTED" != "None" ]; then
> + cp -f $EE.tmp $EE
> # Add a newline in case last line does not have one
> echo >> $EE.tmp
> echo "LANG=$SELECTED" >> $EE.tmp
It's sure this patch cannot be applied straightforwardly because it
ignores the comment argument.
Regards,
-- gotom
> > problem: locales.postinst overwrites the LANG setting in
> > /etc/environment in each upgrade, making it impossible to manually
> > maintain it.
> BTW, why do you want to maintain this file manually? Is
> dpkg-reconfigure locales insufficient for you?
until yesterday, I was not aware that the locales package had debconf
suport for LANG in /etc/environment. now I know, I may consider
handing the maintenance to debconf, but I filed the bug since I
suddenly had my hand-maintained file overwritten. which is a bug.
> "None" means "I don't want to set LANG variable to /etc/environment".
> In this case, I think adding "Don't touch /etc/environment" entry is
> appropriate like "Don't touch keymap" in console related package (I
> forgot the actual package name, but I guess you know it). In
> addition, "None" is vague name - I propose it as "Don't set LANG" and
> so on.
I agree with that approach.
thanks,
--
Adeodato Simó
EM: asp16 [ykwim] alu.ua.es | PK: DA6AE621
Listening to: Múm - Finally we are no one
We may not return the affection of those who like us, but we always
respect their good judgement.
--
To UNSUBSCRIBE, email to debian-bugs-...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
No, locales.config parses this file in order to catch user's settings.
I can see two reasons why this could fail:
a. locales.config is unable to parse /etc/environment.
b. The selected locale is not listed in SUPPORTED.
About (a), the format of /etc/environment is mostly unspecified, so
it is not worth trying to fix this parsing, the right solution is to
let the locales package handle its own configuration file.
About (b), I am not sure how to best fix it, but this bugreport should
then be retitled.
Denis
It's no problem. locales.config just parses /etc/environment even if
there's unknown LANG settings. Is this proposed patch insufficient
for /var/lib/dpkg/info/locales?
--- locales.postinst 2004-09-28 00:22:48.000000000 +0900
+++ locales.postinst 2004-10-02 10:14:38.000000000 +0900
@@ -53,6 +53,7 @@
/usr/sbin/locale-gen
# Set default LANG environment variable
+ if [ "$SELECTED" != "Don't modify settings" ]; then
if [ -e $EE ]; then
sed -e '/^ *LANG=/d' $EE > $EE.tmp || true
# $EE has to be updated if $SELECTED is empty or 'None'
@@ -68,6 +69,7 @@
cat -s $EE.tmp > $EE
fi
rm -f $EE.tmp
+ fi
fi
# We remove a relic of the past /usr/doc/<package> symlinks.
--- locales.templates 2004-09-28 00:22:46.000000000 +0900
+++ locales.templates 2004-10-02 10:14:38.000000000 +0900
@@ -111,7 +111,7 @@
Template: locales/default_environment_locale
Type: select
-Choices: None, ${locales}
+Choices: None, Don't modify settings, ${locales}
Choices-cs.ISO-8859-2: ®ádné, ${locales}
Choices-da.ISO-8859-1: Ingen, ${locales}
Choices-de.ISO-8859-15: Keine, ${locales}
> b. The selected locale is not listed in SUPPORTED.
> About (a), the format of /etc/environment is mostly unspecified, so
> it is not worth trying to fix this parsing, the right solution is to
> let the locales package handle its own configuration file.
I would like to know: why can console-data have "Don't touch keymap",
but can't locales have "Don't touch /etc/environment"?
> About (b), I am not sure how to best fix it, but this bugreport should
> then be retitled.
I think there're two reasons to improve this area:
(1) Some locales have alias name because of historical reason. For
example, ja_JP.EUC-JP is listed in SUPPORTED, but I prefer to
use ja_JP.eucJP. eucJP is alias of EUC-JP.
(2) If we want to use new locale for local experiment, we have no
idea to keep such locale in /etc/environment. It's not enough
reason for users, though.
So I think "Don't touch /etc/environment" is good idea to introduce it.
Regards,
-- gotom
It fails if for instance there are spaces before LANG=
[...]
> > b. The selected locale is not listed in SUPPORTED.
> > About (a), the format of /etc/environment is mostly unspecified, so
> > it is not worth trying to fix this parsing, the right solution is to
> > let the locales package handle its own configuration file.
>
> I would like to know: why can console-data have "Don't touch keymap",
> but can't locales have "Don't touch /etc/environment"?
The difference is that locales interact with a configuration file.
This option was there months ago (named then "Leave alone") and
http://lists.debian.org/debian-glibc/2003/04/msg00270.html
was about its removal (among other things).
> > About (b), I am not sure how to best fix it, but this bugreport should
> > then be retitled.
>
> I think there're two reasons to improve this area:
>
> (1) Some locales have alias name because of historical reason. For
> example, ja_JP.EUC-JP is listed in SUPPORTED, but I prefer to
> use ja_JP.eucJP. eucJP is alias of EUC-JP.
>
> (2) If we want to use new locale for local experiment, we have no
> idea to keep such locale in /etc/environment. It's not enough
> reason for users, though.
>
> So I think "Don't touch /etc/environment" is good idea to introduce it.
I disagree. Another solution is to add the current value found in
/etc/environment to the list of choices so that it can be selected,
the problem then is that this locale may not exist.