I use a special proxy account for portage. I noticed that emerge uses the shell's environment variable settings for http_proxy instead of using the settings specified in make.conf. In other words: If having http_proxy exported within the shell, the settings for http_proxy in make.conf are ignored. I think this should behave vice versa. Reproducible: Always Steps to Reproduce: 1.Test emerge with an http_proxy setting in make.conf => works 2.Export http_proxy within your shell (different settings than in make.conf) 3.Emerge uses the settings from your shell environment instead of the settings in make.conf Expected Results: Emerge should prefer the settings in make.conf. This bug might be difficult to diagnose by a user as the settings within make.conf are valid but ignored.
The long-standing emerge behavior is for the calling environment to be able to override make.conf settings. We can certainly add an option to ignore the calling environment completely, and call it --ignore-calling-env [ y | n ] so that you can put it in EMERGE_DEFAULT_OPTS and then temporarily disable it on the command line if you ever want to.
In general you're right - the problem I see, or why I got problems with this behaviour is that http_proxy might be exported by default within the shell. So you (at least I) setup make.conf and run emerge and wonder why it doesn't work. Perhaps one should use another variable than http_proxy for emerge's proxy configuration. Just an idea ...
If we use a different variable then it will break existing configurations. It seems odd that your proxy configuration varies like this. I don't remember anyone else complaining about this in as many years as I've been fixing portage bugs.
You're of course right - and for me this doesn't need to be 'fixed' as I know now how to handle this. I fully understand your position and it was just an idea as I needed some time to find the reason for emerge not working for me as expected. However, before breaking existing setups keep it as it now works, perhaps some hint within the documentation might be helpful for others who might run into this problem (if such hints don't already ecist within the current docs). At all this 'bug' might be closed if there's no more input regarding this issue. Regards
