Bug#636086: [PATCH] Use C.UTF-8 from current libc-bin, rather than our own private en_US.UTF-8

[Niels Thykier <niels@thykier.net>]

On 2011-08-02 18:23, Niels Thykier wrote:
> On 2011-07-31 00:56, Josh Triplett wrote:
>> I've attached a git patch fixing this bug.
>>
>> I omitted the debian/changelog entry to avoid spurious conflicts, but
>> the contents of the git changelog should work for that purpose.
>>
>> Please consider applying this patch.
>>
>> Thanks,
>> Josh Triplett
> 
> Hi
> 
> Thanks for the interest and the patch.  Personally I like the patch, but
> it may complicate backporting[1].  So I would like comments from Tolimar
> (our backporter, CC'ed) before I apply this.
> 
> ~Niels
> 
> [1] The relevant libc-bin is not in squeeze/squeeze-backports, so
> effectively this commit has to be "undone" on every backport.
> 

Okay, a second take on this...

How about we migrate to C.UTF-8 in all cases; if the system provides one
in /usr/lib/locale/C.UTF-8, then we use that otherwise we fall back to
our internal locale.

postinst/prerm are modified to remove the old en_US.UTF-8 locale.  If
/usr/lib/locale/C.UTF-8 exists; remove /var/lib/lintian/locale (if it
exists).
  Otherwise generate a C.UTF-8 locale in /var/lib/lintian/locale as we
have done in the past.

This way we migrate to C.UTF-8 in all cases, keeping the internal code
free from a lot of "pick en_US.UTF-8 or C.UTF-8" code snippets.  It
should keep backporting trivial as far as I can tell.

Finally, if we start this transition now, our maintainer scripts +
triggers should be redundant for Wheezy+1.

There is the assumption that /usr/lib/locale/C.UTF-8 will not disappear;
that is no one will downgrade libc-bin below 2.13-1, but I think that is
a fair assumption (testing has 2.13-10 atm, so they would have to
downgrade via snapshots).  Even if they do, the lintian scripts will
correct itself on a reinstall or upgrade.

Let me know if there is any issues or objections to this solution; else
I will look at implementing this sometime next week.

~Niels