On Fri, 20 Jul 2012 12:39:21 -0400 Mike Gilbert <flop...@gentoo.org> wrote: > On Fri, Jul 20, 2012 at 2:54 AM, Ciaran McCreesh > <ciaran.mccre...@googlemail.com> wrote: > > On Thu, 19 Jul 2012 18:34:41 -0400 > > Mike Gilbert <flop...@gentoo.org> wrote: > >> On Thu, Jul 19, 2012 at 5:13 PM, Zac Medico <zmed...@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? > 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
signature.asc
Description: PGP signature
