Matthew Burgess wrote:
I think it's reasonable to install the SUPPORTED file in /usr/share/i18n and explain its usefulness in the book. I don't think we should alter the file in any way - if there are other locales that happen to work, we'd need to enquire with upstream whether that's merely accidental, or whether they are officially supported (and therefore SUPPORTED needs to be updated).
For 8-bit locales, that is not by accident.
We can then ask folks to ensure that the locale our heuristic resulted in also appears in /usr/share/i18n/SUPPORTED. If it does, everything's great, if not, use the closest thing that *is* in the SUPPORTED file.
The non-UTF-8 locale our heuristic results in will almost never appear in the SUPPORTED file as-is. In most cases, the charset field will be dropped. This will be a synonim for glibc, but may or may not be a synonim for other applications.
However, just because it's in SUPPORTED doesn't mean to say that broken packages like Xlib will work, right?
Unfortunately, right.
If Xlib still doesn't work correctly with a SUPPORTED locale, what other options do we have?
Trying the locale our heuristic resulted in (i.e. not dropping the charset field), googling, looking at what the host distro uses.
Whatever it is (aside from patching Xlib), will surely result in recommending a non-SUPPORTED locale which I don't think we want to do.
It is OK to recommend any locale (i.e. any synonim of a locale listed in the SUPPORTED file) if applications work. The main test is NOT to look into the SUPPORTED file. It is to run the example "locale" commands at the bottom of the proposed text, and to run an Xlib-based application.
Unfortunately at least one case is known (against Xlib) where a locale listed in the SUPPORTED file doesn't work with Xlib, but the locale with an explicitly specified charset works. So the SUPPORTED file is mainly a hint that helps determine whether dropping the charset field is safe-for-glibc.
So the summary is: The SUPPORTED file contents are just one more heuristic, known to be not 100% accurate. No single 100% accurate heuristic is known yet, and I am not sure if it exists at all. The UTF-8 LiveCD uses a table containing apparently-working locale values.
Combining the two heuristics (i.e. trying both with the charset field in the canonical form, and, where this results in a synonim for glibc, without this field) is hoped to give good-enough results.
It is even more important that readers should know how to detect failing locales, i.e. know the relevant error messages.
-- Alexander E. Patrakov -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
