Per PMS, none of the variables set in ebuild environment can be modified by ebuilds. This doesn't really make sense for variables TMPDIR and HOME since both are standard system environment variables that can normally be freely altered.
When we allow ebuilds to change these variables, we must specify their behaviour w.r.t. environment saving (for example, what will be their value in pkg_*rm after a package move?). Also, PMS guarantees that TMPDIR and HOME will point to different locations for the install and the replacement, when reinstalling a package. How will you enforce this when ebuilds are allowed to set these variables themselves? I tend to close this as INVALID.
We only mangle it in local scope, relatively to the original value.
Can you describe what your actual usage case is? Usually HOME points to a user's home directory and there is little reason to change it.
We override configuration multiple times, storing different variants (for different Python versions) in separate homedirs. Then we just locally override HOME to enable the appropriate version. The alternative is to keep rewriting (or moving around) the configuration file when switching implementations but that is ugly compared to setting HOME.
(In reply to Michał Górny from comment #4) > The alternative is to keep rewriting (or moving around) the configuration > file when switching implementations but that is ugly compared to setting > HOME. This doesn't sound so complicated. I'd much prefer not to make intrusive changes to the spec for a problem that can be easily solved otherwise.
As a compromise, maybe PMS could disallow only non-local changes to values of these variables? Then 'local -x HOME=...' and 'HOME=... some_command' could still be used.
Various utilities used by the package mangler might misbehave in weird ways if given different values for these variables. I seem to recall this restriction originating because of a security issue along these lines.
