On Wed, 2011-03-02 at 01:14 +0100, "Martin v. Löwis" wrote:
I think a PEP would help, but in this case I would request that before the PEP gets written (it can be a really short one!) somebody actually go out and get consensus from a number of important distros. Besides Barry, do we have any representatives of distros here?
Matthias Klose represents Debian, Dave Malcolm represents Redhat, and Dirkjan Ochtman represents Gentoo.
Current status within RHEL and Fedora: The "python" rpm package has: - a "/usr/bin/python", which is the "system" build of Python 2 - hardlinked with "/usr/bin/python2.N" (where N is the appropriate minor release number; currently 2.7 for Fedora 14 onwards) - a symlink "/usr/bin/python2", pointing at "/usr/bin/python" There are a number of other rpm packages with names matching "*py*", which use the system build of Python 3 There is a "python3" package on Fedora 13 onwards with: - a "/usr/bin/python3", which is the "system" build of Python 3 - hardlinked with "/usr/bin/python3.N" (where N is the appropriate minor release number; will be 3.2 as of Fedora 15) There are number of add-on rpm packages containing 3rd-party Python 3 code with names of the form "python3-*". Some more status on our pre-packaged Python 3 stack can be seen here: https://fedoraproject.org/wiki/Python3 I've also added "python-debug" and "python3-debug" binaries, containing --with-pydebug builds of the same code. On a related note, we have a number of scripts packaged across the distributions with a shebang line that reads: #!/usr/bin/env python which AIUI follows upstream recommendations. There was a proposal to change these when packaging them to hardcode the specific python binary: https://fedoraproject.org/wiki/Features/SystemPythonExecutablesUseSystemPyth... on the grounds that a packaged system script is expecting (and has been tested against) a specific python build. That proposal has not yet been carried out. Ideally if we did this, we'd implement it as a postprocessing phase within "rpmbuild", rather than manually patching hundreds of files. Note that this would only cover shebang lines at the tops of scripts. If a 3rd-party program launches python directly, that could fail, and I don't see a convenient way of fixing every reference in all code in all packages (without, say, running a SystemTap script to monitor for programs exec-ing "/usr/bin/python") For example, I wonder what the automake macro for detecting python would make of a /usr/bin/python that's python 3: http://www.gnu.org/software/hello/manual/automake/Python.html I've seen a few hand-coded makefiles for Python extension modules that were broken by the SOABI changes in PEP 3149. To be fair, thouse makefiles were badly written, but I think that changing the meaning of /usr/bin/python would break a lot of things. FWIW, I don't see the harm in providing a /usr/bin/python2 symlink, but I don't plan to change /usr/bin/python at this time. Hope this is helpful Dave