]> code.ossystems Code Review - openembedded-core.git/commit
libc-package.bbclass: add LOCALE_UTF8_IS_DEFAULT
authorRichard Tollerton <rich.tollerton@ni.com>
Fri, 22 Jan 2016 01:46:53 +0000 (19:46 -0600)
committerRichard Purdie <richard.purdie@linuxfoundation.org>
Fri, 29 Jan 2016 17:31:51 +0000 (17:31 +0000)
commitfcde0c43f7b57ec6f8201226ad98e6e46708d288
tree0dde1cf27785327f2c07f4837096d8fc8dba55ee
parent3fc5829915e7212f783448bb27b09196e2831cfb
libc-package.bbclass: add LOCALE_UTF8_IS_DEFAULT

python hard-codes the encoding of many locales; for instance, en_US is
always assumed to be ISO-8859-1, regardless of the actual encoding of
the en_US locale on the system. cf
https://hg.python.org/cpython/file/7841e9b614eb/Lib/locale.py#l1049,
getdefaultlocale(), etc. This code appears to date back to python 2.0.
The source of this hard-coding is Xorg's locale.alias but is ultimately
justified by glibc's SUPPORTED.

This causes problems on OE, because any locale lacking an explicit
encoding suffix (e.g. en_US) is UTF-8. It has been this way from the
beginning (svn r1). That is not a bug, per se -- no specification
prohibits this AFAIK. But it seems to be at odds with virtually every
other glibc-based distribution in existence. To avoid needlessly
aggravating hidden bugs that nobody else might hit, it makes sense to
disable this behavior such that locales are named precisely as specified
by SUPPORTED.

I suppose that reasonable minds may disagree on whether or not the
current behavior is prudent; at the very least, this is likely to break
IMAGE_LINGUAS settings. So let's create a new distro variable
LOCALE_UTF8_IS_DEFAULT to allow either behavior. Set it to 0 and all
your locales get named exactly like they are in SUPPORTED. Leave it at 1
to preserve current OE locale naming conventions.

Signed-off-by: Richard Tollerton <rich.tollerton@ni.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
meta/classes/libc-package.bbclass
meta/conf/distro/include/default-distrovars.inc
meta/conf/documentation.conf