Re: [RFC] locales

[Sergey Lapin <slapinid@gmail.com>]

Paul Sokolovsky wrote:
> 
>         That's true in the sense that there's no special infra to deal
> with l19n issues efficiently. Otherwise, basic support on package
> management level is there and works well (on that very package management
> level).
> 
>         Going for elaboration of this support is opening Pandora's box.
> There going to be just too many issues, and they will swamp whoever go
> for them. At that's at the time, when we have more pressing issues on
> all levels (OE - many packages not up-to-date/broken; Angstrom - lots
> of clean up to do, and finally to make release; Specific devices -
> lotsa kernel and related stuff to support/improve).
I have a feeling that that will go on forever - there are always
broken packages, not to mention improvements, especially on kernel side.
There's no stopping point, and that's not bad.


> 
>         So, I feel like currently it's bad time to go for l19n
> problems.
It seems that good time will never come, since there are always
other things to be done.

>         Yes, as of now, Angstrom is shipped with the default locale
> only. Users who need other locale, can easily install it using package
> manager (and yes, this easiness can be improved even more).

Any interesting details here, please?

> 
>> Infrastructure problem:
>> * We need a way to set up automatic locale package installation during
>> image build according to some subset of languages/locales.
> 
>         On OE level, it's possible. On Angstrom level, we'd need to
> decide which will be that "subset". And one decision was already made
> - as locales (as in glibc locale package) are big in size, and there's
> no definitive subset of size=N, N>1 which will allow to cover needs of
> greater audience than subset of size=N-1, let there be one default
> locale, and let users use standard means of customizing the install -
> a package manager.
It is not possible for some devices, and too hard on others
(due to lack of device support, for example, and need to provide
powerful showcase).

>         Ok, let me just dump my thoughts on how I'd do that:
> 
> 1. Use ROOTFS_POSTPROCESS_COMMAND to do this stuff, don't patch the
> rest of bitbake/OE.
> 2. ROOTFS_POSTPROCESS_COMMAND is run after rootfs is fully created, in
> particular, when all packages are recursively installed. The list of
> them is in /usr/lib/ipkg/status.
> 3. Read the list, and for each package PKG in it, try to install
> package PKG-locale-LL. Skip non-existent packages.
> 4. Voila

And here you provide solution to build image, not solving
issues for user (he installs application and expects
for package manager to install his locales for him
automatically. So, a bit of patching of ipkg is needed.
Any cons?