[oe] [RFC] locales

[Paul Sokolovsky]

Hello Sergey,

Thursday, June 21, 2007, 1:05:19 AM, you wrote:

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

        Nice bit of philosophy in midst of technical/organization
discussion. But even philosophical theory of changes has notions of
"less appropriate" and "more appropriate" for a given event in a given
point of time. Anyway, that was all my IMHO, and YMMV.

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

        My idea is that there should be a tool, frontend to package
manager, allowing to find and install useful things easily for end
user (but not necessarily in optimal way). To not create more entities
than needed, in my dream I see the very package manager reuse for
that, under following scheme:

1. Multiple section support added to ipk's.
2. Package manager provides ability to to filter list by section
(likely already done).
3. A separate section is created, with catchy name like
"Oh-so-cool-goodies".
4. Within that section, there live virtual packages (empty with just
Depends on real packages), within also boring names like "Click here
to install translations for language X" or "Click here to install
bunch'o'games".
5. There's a shortcut on desktop, which starts package manager with
the mentioned section filter applied.

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

        Locales, devices, and phase of the moon have no correlation,
sorry. It should be possible to install any locale on any device
regardless of the moon phase.

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

        You were already provided idea of the corresponding
solution for runtime use on IRC. Just to have it all in one place,
here what it was:

1. You write an app which scans currently installed list of packages.
2. For each package PKG, it tries to install PKG-locale-LL, skipping
any errors.
3. Users run this update-locales tool after installing new packages.

> (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?

        Pretty mad expectations. Lart that user, just in case. But
even that is possible, and of course without (adhoc) ipkg patching. In
the worst case, we can add that update-locales script as post-install
for each package which has locales. But that's again contamination of
metadata. Instead, ipkg should allow global post-install hook, and
update-locales should be there.


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