Before, when LINGUAS was unset, all locales were installed. Now, both emerge and ebuild set LINGUAS="" and no locales are installed. (I'm talking about .gmo files in /usr/share/locales)
Are you refering to a specific ebuild? Please provide a test case.
This can be seen with any proper autotools+gettext-based ebuild, and a simple testcase is: KEYWORDS=~x86 pkg_setup() { env | grep LINGUAS; die; } If LINGUAS is unset, it will print nothing. If LINGUAS is exported as an empty variable, it will say so. The problem is that portage seems to assume that that's the same thing, so that it's safe to always export it. It's not, by design.
Created attachment 96892 [details, diff] don't export empty USE_EXPAND variables This should correct the problem. Please test.
Created attachment 96894 [details, diff] unset empty USE_EXPAND variables This patch uses unset instead of export -n, so that the ebuild/eclass shell code won't see the empty variables either.
They do handle the unset LINGUAS case correctly, but unfortunately, those solutions won't work when the user exports LINGUAS="" (exactly to avoid installing .mo files): in that case, portage will unset it, and gettext builds will install everything.
A quick test suggests that @@ -1609,7 +1641,8 @@ # like LINGUAS. var_split = [ x for x in var_split if x in expand_flags ] var_split.extend(expand_flags.difference(var_split)) - self[var] = " ".join(var_split) + if self.has_key(var) or len(var_split): + self[var] = " ".join(var_split) # Pre-Pend ARCH variable to USE settings so '-*' in env doesn't kill arch. if self.configdict["defaults"].has_key("ARCH"): works, but I'm no portage guy, and I have no idea if this may break something else. :) (Line numbers are messed up, I know.)
Created attachment 96896 [details, diff] Don't export USE_EXPAND variables if they aren't already set and would be emptied In nice patch format...
Thanks, it seems like that patch will cover all of the cases correctly. It's in svn r4441.
Well, "ebuild" meant "ebuild.sh", patch works for me. Any chance for at least an early revision bump ?
I'm planning to do a revbump in about a week. We've got one other regression and I want to wait a little longer to see if anything else is discovered.
This has been released in 2.1.2_pre1.
*** Bug 148702 has been marked as a duplicate of this bug. ***
This has also been released in 2.1.1-r1.