Installing IPython with pip as root will replace /usr/lib/python-exec/python-exec2 with the "ipython" launch script if IPython is already installed from Portage. floppym from IRC seemed to believe this was caused by installing from wheels, and indeed pip installs IPython from a wheel. I have not yet tested to see whether this occurs for other wheel packages using pip. I have confirmed that this occurs for both CPython (using python3.5 -m pip install ipython) and Pypy (using pypy3 -m pip install ipython). Of course I also should not be running pip as root, but it was suggested I submit this as a bug report in the IRC channel regardless. Reproducible: Always Steps to Reproduce: 1. Install multiple Python implementations, e.g. python2_7 and python3_5 2. Install dev-python/ipython with only one implementation in PYTHON_TARGETS, e.g. python2_7 3. Using pip as root, install IPython for the other target, e.g. python3.5 -m pip install ipython Actual Results: /usr/bin/ipython remains a symlink to /usr/lib/python-exec/python-exec2, and the target is replaced with the IPython launch script Expected Results: /usr/bin/ipython should either be replaced by the IPython launch script from pip, or left unchanged. /usr/lib/python-exec/python-exec2 should not be modified at all.
Look for stray open(..., 'w') calls. They like to think it's fine to write straight into files on the system.
wheel/install.py has stray: destination = HashingFile(open(dest, 'wb')) with no check whether destination doesn't already exist. Which obviously makes it clobber symlinks, lock on named pipes, write to device files and do other terrible things.
Well, my original upstream bug was wrong and I don't really know if it still happens. If you hit it again, please reopen.
