On Fri, Jul 20, 2012 at 1:09 PM, Ciaran McCreesh <[email protected]> wrote: > On Fri, 20 Jul 2012 12:39:21 -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. >> >> 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.
