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

Re: Bug#522776: debian-policy: mandate existence of a standardised UTF-8 locale



Giacomo A. Catenazzi dixit:

> If you need a specific locale (as seems from "mksh", not
> sure if it is a bug in that program), you need to set it.

You can only set a locale on a glibc-based system if it’s
installed beforehand, which root needs to do.

> Why does mksh need UTF-8?

The regression tests check if the Unicode mode of mksh is
properly enabled in a UTF-8 locale, and properly disabled
outside of them.

> Mandate
> UTF-8 as default (instead of C/POSIX) would probably
> be worse (and non POSIX conformant).

This is not what I proposed. I proposed that an additional
C.UTF-8 locale shall be available on all Debian systems, to
complement the default 7/8-bit C locale.

> but "C" means "old sysadmin gergo".

Yes, but some programmes basically need that plus UTF-8.
For example, the traditional sorting order, gcc output
warnings, date format, etc.

Note that mksh *is* fine with any locale, UTF-8 or not,
it just makes a distinguishing on the nl_langinfo(CODESET).
However, the *regression test suite* for mksh, run at build
time, needs one UTF-8 locale, and it needs to know which one.
On most systems, this is “en_US.UTF-8”. But Debian, despite
its release goals of UTF-8 support, does not guarantee its
existence. This is what I’d like to have changed.

> So, if I interpret right your problem, the right solution is:
> - mksh should allow all locales and charsets

This part I think you don’t interpret correctly.

> and one of:
> - Debian should mandate (ev. recommend en_US.UTF-8)
>  [ I think it is right on standard installation, but IMHO
>  it could be to strong for a minimal essential base (chroot)]
> - or a "en_US.UTF-8" package dependency should be required.

Right, one of them. Or at least, have the locales pregenerated,
maybe so that I can depend on a "locale_en_US_UTF_8" package.

bye,
//mirabilos
-- 
“It is inappropriate to require that a time represented as
 seconds since the Epoch precisely represent the number of
 seconds between the referenced time and the Epoch.”
	-- IEEE Std 1003.1b-1993 (POSIX) Section B.2.2.2


Reply to: