On 03.09.2010 01:46, Russ Allbery wrote:
Samuel Thibault<sthiba...@debian.org> writes:
Well, it's mostly
- some people saying "it's useless",
- while other people saying "I need it",
and also
- "en_US.UTF-8 is just fine" vs.
- "en_US.UTF-8 sucks, we really need C.UTF-8 instead"
without any convergence.
I think the way to get past that is to make a specific proposal.
With my Lintian maintainer hat on, I need a UTF-8 locale that's guaranteed
to always be available. Right now, we're doing something complicated and
annoying (and fragile on Ubuntu) to generate one on the fly (en_US.UTF-8
just because it's probably always there), and we would love to stop doing
that.
I agree with others in this thread that having a UTF-8 locale without the
collation changes implied by en_US is very useful for various software
packages such as automated test suites that want reproducible results and
were originally written for the C locale.
BTW I think we should wait some more time. Last week I was on
debian-glibc list a bug: printf fails if it find an invalid UTF-8
character (when the locale uses UTF-8). Note it is allowed in POSIX,
which distinguish raw strings and parts which uses locale definitions.
So I don't think a C.UTF-8 is safe.
But a good release goal for squeeze+1.
ciao
cate
--
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4c80f797.5050...@debian.org
