Bug#567496: Package configuration seems broken - locales from /usr/local/share/i18n/SUPPORTED are ignored, the only choices for locales to be generated are "All locales" and "usage: tr (on|off)", all entries in /etc/locale.gen commented out after upgrade which results in no locale support at all
Package: locales
Version: 2.7-18lenny2
Severity: important
During upgrade from 2.7-18 to 2.7-18lenny2 , the content of
/etc/locale.gen was lost, the file contained just commented entries
for a lot of locales I don't use and my system was left broken
and localeless.
Before upgrade, my /etc/locale.gen was an exact copy of
/usr/local/share/i18n/SUPPORTED (contents below).
During dpkg-reconfigure locales, the only offered choices for
locales to be generated were "All locales" and "tr (on|off)".
Whole action looked like this:
hq:~# cat /usr/local/share/i18n/SUPPORTED
en_US UTF-8
cs_CZ UTF-8
sk_SK UTF-8
cs_CZ.ISO-8859-2 ISO-8859-2
cs_CZ.CP1250 CP1250
sk_SK.ISO-8859-2 ISO-8859-2
sk_SK.CP1250 CP1250
hq:~# cp /usr/local/share/i18n/SUPPORTED /etc/locale.gen
hq:~# DEBIAN_FRONTEND=readline dpkg-reconfigure locales
Configuring locales
-------------------
Locales are a framework to switch between multiple languages and allow users to
use their language, country, characters, collation order, etc.
Please choose which locales to generate. UTF-8 locales should be chosen by
default, particularly for new installations. Other character sets may be useful
for backwards compatibility with older systems and software.
1. All locales 2. usage: tr (on|off)
(Enter the items you want to select, separated by spaces.)
Locales to be generated: 2
Many packages in Debian use locales to display text in the correct language for
the user. You can choose a default locale for the system from the generated
locales.
This will select the default language for the entire system. If this system is a
multi-user system where not all users are able to speak the default language,
they will experience difficulties.
1. None 2. usage: tr
Default locale for the system environment: 1
Generating locales (this might take a while)...
Generation complete.
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
LANGUAGE = (unset),
LC_ALL = (unset),
LC_CTYPE = "en_US.UTF8",
LANG = (unset)
are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").
hq:~# sed -e '/^#/d' < /etc/locale.gen
hq:~#
However, all my locales from /etc/locale.gen and /usr/local/share/i18n/SUPPORTED
are supported by libc:
hq:~# cp /usr/local/share/i18n/SUPPORTED /etc/locale.gen
hq:~# locale-gen
Generating locales (this might take a while)...
en_US.UTF-8... done
cs_CZ.UTF-8... done
sk_SK.UTF-8... done
cs_CZ.ISO-8859-2... done
cs_CZ.CP1250... done
sk_SK.ISO-8859-2... done
sk_SK.CP1250... done
Generation complete.
hq:~#
Described behavior differs from Etch (where user-added entries in
locale-gen seems to stay untouched) and Squeeze (where user-added
entries from /etc/locale.gen are added to the list of offered locales
during dpkg-reconfigure and preserved during upgrade without problems).
All locales I use are supported by libc, these are just locale-encoding
combinations that aren't supported by package configuration layer of
Lenny's versions because of the strange voodoo being done there.
For that reason, I added them just to /usr/local/share/i18n/SUPPORTED,
without supplying their definitions in /usr/local/share/i18n/locales/,
as these are not user defined locales, there's no real need to describe
them there and doing so would cause maintenance problems (the
definitions copied to /usr/share/locales/ without a reason wouldn't be
kept up to date).
The problem seems to be a combination of several sub-problems:
1) no support for locales that are supported by libc but not by
package configuration - having to redefine locales (or in my case,
locale-encoding combinations) supported by libc in
/usr/local/share/i18n/locales/ cannot be called support.
2) the ability to completely wipe out all locales on upgrade without even
printing a single warning about that. Leaving /etc/locale.gen untouched
in cases where all existing entries should be wiped out during upgrade
would be much safer. Current behavior is dangerous as the upgrade may
result in a broken system.
3) the ability to offer the only choice "usage: tr (on|off)" instead of
list of locales (completely mysterious to me at this moment).
These problems quite resemble closed bug #494468, and as neither generated
locale.gen nor its manual page contains any warning or explanations
about not preserving user changes to that file, even this bug might
be considered to be a violation of Debian policy.
Regards,
grunge
-- System Information:
Debian Release: 5.0.3
APT prefers stable
APT policy: (500, 'stable')
Architecture: i386 (x86_64)
Kernel: Linux 2.6.31.6-grng (SMP w/2 CPU cores; PREEMPT)
Locale: LANG=C, LC_CTYPE=en_US.UTF8 (charmap=locale: Cannot set LC_CTYPE to default locale: No such file or directory
locale: Cannot set LC_ALL to default locale: No such file or directory
ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/bash
Versions of packages locales depends on:
ii debconf [debconf-2.0] 1.5.24 Debian configuration management sy
ii libc6 [glibc-2.7-1] 2.7-18lenny2 GNU C Library: Shared libraries
locales recommends no packages.
locales suggests no packages.
-- debconf information:
* locales/default_environment_locale: None
* locales/locales_to_be_generated: usage: tr (on|off)
Reply to: