Bug#321580: locales: installation fails because of sr_YU@cyrillic

[Denis Barbier <barbier@linuxfr.org>]

severity 321580 important
thanks

On Sat, Aug 06, 2005 at 12:57:28PM +0200, Vincent Lefevre wrote:
> Package: locales
> Version: 2.3.5-3
> Severity: grave
> Justification: renders package unusable

The locales package has the same behavior in stable, testing and
unstable, so I downgrade this bug to not hold back glibc migration
to testing.  This can also be performed by a combination of sid,
etch or sarge tags, but I do not know how ;)

> When I try to install the locales package (as an upgrade):
> 
> Setting up locales (2.3.5-3) ...
> Generating locales (this might take a while)...
[...]
>   lt_LT.ISO-8859-13... done
>   sr_YU.ISO-8859-5@cyrillic...cannot open locale definition file `sr_YU@cyrillic': No such file or directory
> dpkg: error processing locales (--configure):
>  subprocess post-installation script returned error exit status 4
> Errors were encountered while processing:
>  locales
> E: Sub-process /usr/bin/dpkg returned an error code (1)
> 
> And "dpkg-reconfigure locales" fails too:
> 
> /usr/sbin/dpkg-reconfigure: locales is broken or not fully installed
[...]

So the problem here is that a locale listed in /etc/locale.gen is
not valid.  There are several possible causes:
  a. This locale was previously listed in /usr/share/i18n/SUPPORTED,
     but has been dropped.
  b. Admin made a typo when editing /etc/locale.gen
  c. This locale exists but is broken.
  d. This locale is broken, and is not provided by the locales package
     but is a local addition.

When an error occurs, we can either abort (this is the current behavior),
or continue.  The former ensures that errors are caught and dealt with,
but admin has then to modify a file he is not even aware of.  With the
latter, an admin may generate all locales without noticing that
sr_YU@cyrillic is broken.  Maybe a good compromise is to not abort when
generating locales, and add a debconf note if errors occured?  (And either
abort after explaining admin how to fix the problem, or exit gracefully)
Honestly I do not know how to best handle all cases listed above.

It would also be very nice to have locale-gen recognize an ALL keyword
in /etc/locale.gen, to generate all locales listed in SUPPORTED.  At
the moment, one has to generate all locales, then copy the new SUPPORTED
file into /etc/locale.gen, and generate all locales again, which is
quite painful.  I will propose a patch if this is seen as a good idea.

Denis