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

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

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.

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.



-- System Information:
Debian Release: 5.0.3
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: i386 (x86_64)

Kernel: Linux (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
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: