Summary: | /etc/profile.env overwrites variables given on command-line | ||
---|---|---|---|
Product: | Portage Development | Reporter: | Xake <kanelxake> |
Component: | Core | Assignee: | Portage team <dev-portage> |
Status: | RESOLVED DUPLICATE | ||
Severity: | normal | CC: | miha.pirnat, tomascohen, truedfx |
Priority: | High | ||
Version: | 2.1 | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
Xake
2006-04-17 02:20:35 UTC
Oh, and it worked with versions 1.5.0.1* sv_SE.UTF-8 isn't a valid LINGUAS setting and is supposed to be ignored completely, and is for me. Do you perhaps have some bashrc stuff that changes LINGUAS too late for portage to see it? Apparently SOMETHING changes it. The only value I have set is in /etc/env.d where it is set to LANG="sv" and this is honored in console, but as soon as my gdm/gnome starts this settings is changed to sv_SE.UTF-8 and I have no clue where and why this is done. LANG and LINGUAS are related but not the same. The value for LANG is not incorrect, but even if it were wouldn't be a problem. Could you please check if LINGUAS gets changed? Both LANG and LINGUAS is changed if i export in a gnome-terminal, but I do not know where and when, must be somewhere within my grafical env as if I do Ctrl+Alt+F1, login and 'export' shows the correct values (which for both is in env.d assigned "sv". It's not so much that your LINGUAS is changed *to* sv_SE.UTF-8 that causes the build failure, it's that it gets changed *back from* sv_SE.UTF-8 at the wrong time. If it weren't changed back, you'd have a fully functional mozilla-firefox. (It would be in English, so you still have to figure out yourself why it got changed in the first place, but aborting isn't good.) You said you set your LANG in /etc/env.d/, do you set your LINGUAS there too? If so, there is the problem; portage sources /etc/profile.env (generated from /etc/env.d/) after it expands USE variables. A simple test case: test-1.0.ebuild: KEYWORDS="~x86" pkg_setup() { echo ${LINGUAS} echo ${USE} die } /etc/env.d/99linguas: LINGUAS='en en_GB' Run `LINGUAS='nl' emerge test/test` and you'll see USE's linguas_* don't match with LINGUAS anymore. So it would be nice if portage would make USE_EXPANDed variables read-only before sourcing profile.env; this would ensure they're kept in sync. Actually, making them read-only would be a bad idea, that would break things like strip-linguas, but what would be possible is to not read them in the first place (for example, by not sourcing /etc/profile.env, but if it must be read at all, only eval'ing the lines which don't set USE-changing variables). I have everything set up in 02locale, LC_ALL LINGUAS LANG.... LC_ALL="sv_SE.UTF-8", the rest just sv. So whats happening short said is that my DE seems to set up LINGUAS="sv_SE.UTF-8" and emerge uses it until it is time for unpack when it sources env.d (where only the above mentioned is) directly and thats the reason I can't emerge? *** Bug 130587 has been marked as a duplicate of this bug. *** actually, the problem isn't specific to USE_EXPAND at all, so rather than setting USE_EXPAND readonly, we just dump the env before the sourcing and go back to that right afterwards. fixed in rev 3300 Maybe I'm misunderstanding, but I thought the point of sourcing profile.env was to ensure that important variables would be set to something sane, which would mean for most variables, whatever's in the current environment needs to be ignored. I may well be wrong though :) If it's intended to let the user override everything, wouldn't it be better to not source profile.env at all, since unset variables mean a) the user did so explicitly, meaning it's probably meant to remain unset, or b) the user hasn't logged in or re-sourced /etc/profile since the last update, which causes problems with the current approach too? *** Bug 123563 has been marked as a duplicate of this bug. *** right, brian harring pointed out that there are various issues with the env dumping and the solution is not so easy, so i reverted rev 3300 until i can come up with something that actually works in all cases. besides, this is bug 51370 :) *** This bug has been marked as a duplicate of 51370 *** *** This bug has been marked as a duplicate of 51370 *** |