[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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



On Sat, Aug 06, 2011 at 03:23:12PM +0200, Niels Thykier wrote:
> 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.

This sounds reasonable to me.  However, I have a suggestion for a slight
variation.  Rather than implementing a private C.UTF-8 locale in lintian
(and preserving the LOCPATH propagation and related bits), how about
creating a new backport-specific package "c-utf8-locale-backport" or
similar, which generates the locale system-wide?  Lintian could then
depend on libc-bin (>= 2.13-1) | c-utf8-locale-backport, and (with some
coordination) the libc-bin maintainers could add a
conflicts/replaces/provides on c-utf8-locale-backport.  Then, lintian
and any other package wanting to count on C.UTF-8 could use this
dependency (and drop the alternative when wheezy releases).

How does that sound?

- Josh Triplett



Reply to: