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

[Mike Gilbert <floppym@gentoo.org>]

On Fri, Jul 20, 2012 at 1:09 PM, Ciaran McCreesh
<ciaran.mccreesh@googlemail.com> wrote:
> On Fri, 20 Jul 2012 12:39:21 -0400
> Mike Gilbert <floppym@gentoo.org> wrote:
>> On Fri, Jul 20, 2012 at 2:54 AM, Ciaran McCreesh
>> <ciaran.mccreesh@googlemail.com> wrote:
>> > On Thu, 19 Jul 2012 18:34:41 -0400
>> > Mike Gilbert <floppym@gentoo.org> wrote:
>> >> On Thu, Jul 19, 2012 at 5:13 PM, Zac Medico <zmedico@gentoo.org>
>> >> 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?
>

Firstly, if there are no linugas_ flags in IUSE, I can't see any point
in such a dependency.

Given the current behavior, I believe the dependency would always
satisfied due to the (+). That seems fine to me.

>> 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.
>

It was a normal variable before someone added it to USE_EXPAND. From
cvs, it looks like that happened in 2005 or so.

>> 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.
>

I beleive LINGUAS originates from the autoconf macros (po.m4) provided
by the gettext package. I believe we added it to USE_EXPAND some time
after it was implemented in gettext. This "just works" given the
current portage behavior.

Perhaps we need to provide a cleaner way for ebuilds to specify if a
given variable should be treated as a USE_EXPAND or not.