Re: (patch) regression diffs on collate.linux.utf8 test

On ons, 2011-10-19 at 01:10 -0400, Tom Lane wrote:
> Jeff Davis <pgsql(at)j-davis(dot)com> writes:
> > On Tue, 2011-10-18 at 22:25 +0300, Peter Eisentraut wrote:
> >> Presumably because Jeff doesn't have that particular locale installed.
> >> locale -a would clarify that.
>
> > $ locale -a |grep -i tr
> > tr_CY.utf8
> > tr_TR.utf8
>
> > So, yes, I only have the UTF8 version.
>
> Wow, that's interesting. Digging around on my Fedora box, I can't find
> any suggestion that it's even possible to subdivide the locale settings
> like that. I only see one source file for tr_TR --- that's
> /usr/share/i18n/locales/tr_TR --- and it looks like all the stuff under
> /usr/share/i18n/locales/ is compiled into one big run-time file
> /usr/lib/locale/locale-archive.

It has "always" been the case on Debian that it doesn't blindly install
all 600+ locales provided by glibc. Instead, the OS installer picks the
ones that you are likely to use, and generates those from source at the
time the "locales" package is installed. (So the locales package
contains the source for all glibc locales, but not the binary form.)

In fact, here is the output from a vanilla Debian stable installation:

$ locale -a
C
en_US.utf8
POSIX

I suspect, and this is Ubuntu-specific, so I don't have direct
experience with it, that what happened is that when you install the
langpack packages that Jeff mentioned, it triggers the compilation of
the respective associated locales. But as you can see, apparently only
utf8 locales are generated by default, nowadays.