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.
How do you figure that? 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. 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.
