| Summary: | python eclasses do not unset PYTHONPYCACHEPREFIX | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Tom Gillespie <tgbugs> |
| Component: | Eclasses | Assignee: | Python Gentoo Team <python> |
| Status: | UNCONFIRMED --- | ||
| Severity: | normal | CC: | sam |
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | All | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
This is a bit niche because there's a huge number of environment variables that, if set, interfere with various build systems. But I suppose we could unset it or add it to ENV_UNSET. Following up here. While trying to test scipy ebuilds as a non-root user I have encountered an issue where manually calling unset PYTHONCACHEPREFIX and unset PYTHONPATH somehow do not prevent those values from making it through into the environment and preventing meson/pypy3 from finding /usr/lib/pypy3.9/site-packages. Those two in particular seem like recipes for madness and should probably be unset by default to avoid weird cases like this. |
If PYTHONPYCACHEPREFIX is set (e.g. by a user) then sandbox violations are caused during emerge of python ebuilds for >=dev-lang/python-3.8. Reproducible: Always Steps to Reproduce: 1. Set PYTHONPYCACHEPREFIX=/path/that/will/cause/a/sandbox/violation 2. emerge setuptools 3. Enjoy knowing that the portage sandbox keeps you safe from rogue builds. Expected Results: PYTHONPYCACHEPREFIX should be unset or should be set ${EPREFIX}${PYTHONPYCACHEPREFIX} from a system wide PYTHONPYCACHEPREFIX set in /etc/env.d/.