On Fri, 20 Jul 2012 13:55:46 -0400 Mike Gilbert <[email protected]> wrote: > On Fri, Jul 20, 2012 at 2:54 AM, Ciaran McCreesh > <[email protected]> wrote: > > On Thu, 19 Jul 2012 18:34:41 -0400 > > Mike Gilbert <[email protected]> wrote: > >> On Thu, Jul 19, 2012 at 5:13 PM, Zac Medico <[email protected]> > >> 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. > > Do you mean that LINGUAS will be empty, or unset (undefined) in an > ebuild context? The difference is significant here.
For EAPIs before 5, LINGUAS contains *at least* the things in IUSE intersected with the ones the user has enabled, with the linguas_ stripped. It's not just "the environment variable in make.conf", since a user might put linguas_en in package.use. For EAPIs 5 and onwards, LINGUAS contains only those things, and definitely won't contain anything else. -- Ciaran McCreesh
signature.asc
Description: PGP signature
