[oe] [RFC] locales

[Paul Sokolovsky]

Hello Sergey,

Wednesday, June 20, 2007, 1:14:41 PM, you wrote:

> Hi, all!

> Note: I could be fundamentally wrong here, so, please feel free to
> point me to right direction in this case.

> As it was discussed on #oe, locale infrastructure lacks implementation
> on oe.dev, and, in particular, in Angstrom.

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

        So, I feel like currently it's bad time to go for l19n
problems.

> With a bit of research I done on this subject made me to come up with
> a few ideas, which I'd like to know your opinion about.

> Present status:
> *-locale* packages are generated, but not put on image. These packages
> contain message translations.
> * Only glibc locale which is put on image (if any) is en_GB.

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

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

> * We need a way to install "language" in simple user-friendly way. I
> mean here not only locale packages, but also various
> language-dependent files (docs, keymap settings, various configuration
> files, etc.).

> Various random problems encountered:
> * GPE locale.alias for gpe-dm needs cleanup (get rid of non-UTF8 locales?)
> * libx11 locale.alias needs cleanup (setup for UTF8-only system).

> So, if we go utf8-only, we need to do a great cleanup/testing job here
> to settle things up.

> As for infrastructure, I see several questionable methods of solving this:

> 1. each package RRECOMMENDS its locale packages for locales mentioned
> in local.conf variable, and additional ones, which are related.

> 2. image RRECOMMENDS locale packages blindly for all normal packages
> for languages which are in a var mentioned in 1.

        These games with dependencies will do more harm than good.
l19n is pretty specific thing, and requires adhoc handling on another
level.

> 3. all -locale packages generated during builds are written to some
> special lists, for each language. Then meta-packages are generated
> from these lists.

        And this sounds a bit tangled. What such list will give you?
Why it needs to be written while generating packages? Why
"ls deploy/ipk/" is worse than such list?



        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


> ...

> So, any ideas?

-- 
Best regards,
 Paul                            mailto:pmiscml at gmail.com