Re: [gentoo-dev] RFC: l10n.eclass

[Ciaran McCreesh]

On Fri, 20 Jul 2012 12:39:21 -0400
Mike Gilbert <floppym@g.o> wrote:
> On Fri, Jul 20, 2012 at 2:54 AM, Ciaran McCreesh
> <ciaran.mccreesh@××××××××××.com> wrote:
> > On Thu, 19 Jul 2012 18:34:41 -0400
> > Mike Gilbert <floppym@g.o> wrote:
> >> On Thu, Jul 19, 2012 at 5:13 PM, Zac Medico <zmedico@g.o>
> >> wrote:
> >> > On 07/19/2012 06:14 AM, Ralph Sennhauser wrote:
> >> >> Could be that Portage re-exports a sanitized
> >> >> LINGUAS tough, but I doubt it.
> >> >
> >> > Portage does sanitize it if there are any linguas_* flags in
> >> > IUSE, otherwise it lets the variable pass through without
> >> > sanitizing it.
> >>
> >> That's good; we definitely don't want to "sanitize" it if there
> >> are no linuguas_* flags in IUSE. This would break LINUGUAS support
> >> for many autotools/gettext based packages, where the autotools
> >> code parses LINGUAS directly and the ebuild does nothing with it.
> >
> > If there aren't any linguas_* flags in IUSE, LINGUAS should be
> > empty, and will be in future EAPIs. Without that, USE dependencies
> > on USE_EXPAND variables don't work.
>
> How do you figure that?

If you dep upon foo[linguas_en(+)] and linguas_en isn't in IUSE, what
happens?

> The current portage behavior works well enough; if linugas_* is in
> IUSE, LINGUAS is treated as a USE_EXPAND, and use-deps should work
> fine.
>
> Otherwise, it is treated just like a normal environment variable, and
> portage doesn't touch it.

It's not a normal environment variable, and it never has been.

> For most gettext packages, there is absolutely no reason that the
> ebuild maintainer should have to keep track of every translation
> available in a given package across version bumps. If you change this
> behavior in a future EAPI, you will break this.

Don't use a USE_EXPAND variable if you don't want USE_EXPAND behaviour.

-- 
Ciaran McCreesh