Re: [gentoo-dev] [RFC] ban use of base-4 casemods in ebuilds due to locale collation instability

[Michał Górny]

On Wed, 11 Nov 2015 07:16:42 +0100
Patrick Lauer <patrick@g.o> wrote:

> On 11/11/2015 03:51 AM, Mike Frysinger wrote:
> > On 10 Nov 2015 18:53, Mike Frysinger wrote:
> >> i randomly stumbled across an ebuild that was using ^^ to make a variable
> >> uppercase.  this is new to bash-4.0 and thus invalid for EAPI=[0-5].  only
> >> the fresh EAPI=6 permits it since we bumped the min ver to bash-4.2.
> > Arfrever highlights these are not even safe to use.  bash is locale aware,
> > so it'll apply LC_COLLATE rules when processing the ^/, casemods.  while
> > you can fix this with external programs ala:
> > 	LC_COLLATE=C tr ...
> >
> > you can't do it with inline code like:
> > 	LC_COLLATE=C SRC_URI=".../${PN^^}/..."
> >
> > you can if you do something like:
> > 	SRC_URI=".../$(LC_COLLATE=C; echo "${PN^^}")/..."
> >
> This points out a class of problems we've hit in the past: locale-aware
> things in ebuilds.
>
> Wouldn't it be 'easier' (fsov easy) to have portage use sane-default
> locale settings, so that estonian or turkish users don't get hit by
> weirdness in the [a-z] character class etc.?
>
> (And as a side-effect the build logs are always readable ;) )

Pretty much +1 here. Not saying we need to force full locale, but
having sane LC_CTYPE and LC_COLLATE would make sense. PMS already
forces it in a few places... we may as well force it globally.

-- 
Best regards,
Michał Górny
<http://dev.gentoo.org/~mgorny/>