Fix shebang line of system Python executables
System executables written in Python now use a shebang line that explicitly references the system version of Python.
Remove the "#!/usr/bin/env python" shebang line from python executables, replacing with "#!/usr/bin/python"
- Name: Dave Malcolm
- Email: <firstname.lastname@example.org>
- Targeted release: Fedora 16
- Last updated: 2011-05-24
- Percentage of completion: 0%
Fedora ships numerous executables written in Python. Many of them contain the shebang line:
However, this makes it difficult to install alternative versions of Python on the system. If a user wishes e.g. to install python 3 on the system, and have a /usr/local/python in her PATH, this will break these executables.
These system executables are expecting to use the system python, and thus should use:
The shebang line should also contain carefully-chosen command line options for invoking python for a system executable.
FIXME: does this work? do the command-line args from the shebang get appropriately combined with those from the invocation of the exectuable?
As of Python 2.6 and 3.0, Python supports loading user-specific Python libraries, as per PEP-370, which is helpful for Python developers, but isn't appropriate for system executables, and could be a security issue. It can also lead to warnings from SELinux - see e.g. RHBZ #614025. The shebang line for a system executable should thus contain the "-s" argument, to suppress PEP-370.
Benefit to Fedora
Users will be able to parallel-install local copies of older and newer releases of Python on the system and add them to the front of their PATH without breaking these executables. (e.g. Python 2.4 for Zope, or Python 3)
Requires lots of one-liner fixes to numerous packages; exact list TBD.
Creation of an rpmlint test to detect usage of
#!/usr/bin/env shebang lines.
- add a test to rpmlint ?
Should be no user-visible change for non-Python experts.
Python developers and users wishing to parallel-install a local version of Python should now be able to add it to the front of their PATH without breaking these apps.
None; I believe that this is a collection of tiny fixes to many packages, each with minimal risk.