[Python-Dev] Support the /usr/bin/python2 symlink upstream

[David Malcolm]

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