Subject pretty much says it all.  Currently *everything* from the users env winds up being available to ebuilds.
This complicates the hell out of my job of maintaining env handling (saving, transfering, reloading) in portage-cvs- 
having literally hundreds of env vars defined prior to even adding in the ebuild/eclass/portage env additions.

So... yeah.  Anyone got a good reason why all vars should be dumped into the ebuild environment?  I don't see the 
point in all of my binpkgs having my ECHANGELOG_USER setting, for example.

Assuming no one can come up with a valid reason why the entire user env must be dumped into the compilation 
environment, whitelisting of vars that are allowed in would be the next step.  LINGUAS, EXTRA_ECONF, etc.

Portage cvs already does it's own filtering of the vars it knows don't belong in the env- portage innard vars for 
example, are explicitly removed from any saved env.  The reason behind this is that portage wants to control those 
vars itself, basically striving for a controlled environment for ebuild execution (whether setup phase or compile).

I don't see why the same control shouldn't be extended to the portions of a users env that get pulled in.  
Ultimately, a user can sidestep it also via profile and portage bashrcs (so it's not a total lockdown on the env).

Thoughts?
~harring