Tuesday, 4 June 2013

Re: Systems with invalid locales

On Tue, 4 Jun 2013, Adam Conrad wrote:

> On Tue, Jun 04, 2013 at 04:18:40AM -0600, Adam Conrad wrote:
> >
> > I wonder if it might be high time to discuss slapping C.UTF-8 in the
> > default locale in pretty much every minimal installation scenario we
> > can think of (obviously, still overriding in more complex installers
> > that allow a user to choose a properly local locale).
>
> And on a vague tangent from that, it might also be getting close to a
> point where we should discuss switching buildds to C.UTF-8 too (they
> currently force C). My gut feeling is that this shouldn't have much
> effect, with the following assumptions:
>
> 1) Most packages and testsuites shouldn't care what locale they're
> run in in the first place (but it doesn't seem to make sense to
> test in a locale almost no one uses in production, while a UTF-8
> locale will at least trip a few curious issues real people see)
>
> 2) Most packages that do require being in C for their builds or for
> their testsuite probably already force this, because maintainers
> have been working in fancy locales for years now, and they've
> had to force C where needed to make things work outside chroots.
>
> Pretty sure we *would* run into some packages (especially older ones)
> that would fail in a UTF-8 locale, but I think the general benefit of
> building in a locale more similar to 99% of people's runtime locales
> would be a net win, even if we have to fix builds and testsuites to
> cope.
>
> Thoughts?

I have the memory, not substantiated by evidence, that some things (i
recall 'grep') to be much faster with LANG=C than with a more fancy
locale.

I couldn't seem to reproduce this with a quick grep or egrep for a string
through /bin. I just recall that at some point in my life 'LANG=C' made
stuff a whole lot faster. Ie, LANG=C.utf-8 could actually slow down
builds. My memory, though is from the 2003 era, so its entirely possible
that massive speedups have occurred in string processing of non-C locales
since then.

Scott

--
ubuntu-devel mailing list
[email protected]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel