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/SystemPythonExecutablesUseSystemPython
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
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
