(Add reasons not to use subpackages) |
(Byte compilation recipe) |
||
| Line 61: | Line 61: | ||
If you want a python26 version of a package that's in EPEL5, you should also make a separate src.rpm. There are several reasons that the separate src.rpm is preferable in EPEL vs using the same src.rpm and separate subpackages. | If you want a python26 version of a package that's in EPEL5, you should also make a separate src.rpm. There are several reasons that the separate src.rpm is preferable in EPEL vs using the same src.rpm and separate subpackages. | ||
* In EPEL, we're bound to keep backwards compat. However, people who want to deploy a python2.6 package are likely to want the latest and greatest versions of supporting python modules as well. Separate SRPMs gives us the flexibility, both at initial review, and if we decide we need to make an exception to upgrade something to an incompatible version in the future to do this for only the python2.6 package. | * In EPEL, we're bound to keep backwards compat. However, people who want to deploy a python2.6 package are likely to want the latest and greatest versions of supporting python modules as well. Separate SRPMs gives us the flexibility, both at initial review, and if we decide we need to make an exception to upgrade something to an incompatible version in the future to do this for only the python2.6 package. | ||
* Deploying as a subpackage is more limiting. If bugs exist on only one version of the python interpreter, we still have to update the module for both python-2.4 and python-2.6 which could be more churn for users or introduce unintentional new bugs on the other interpreter version. | * Deploying as a subpackage is more limiting. If bugs exist on only one version of the python interpreter, we still have to update the module for both python-2.4 and python-2.6 which could be more churn for users or introduce unintentional new bugs on the other interpreter version. Similarly, if an update of a package is needed to fix a bug on one version of the interpreter but that update is known broken on the other version, you don't have the ability to update one but not the other. | ||
=== Byte compiling === | |||
In Fedora, rpm has a byte compilation script that makes sure that python modules in their respective python*sitearch and python*sitelib directories are byte compiled with the correct version of python. In RHEL5, the byte compilation script uses the system python (python-2.4) for everything. To make byte compilation work, you need to override the script that's being used like this: | |||
<pre> | |||
%global __os_install_post %__multiple_python_os_install_post | |||
</pre> | |||
=== TODO: === | === TODO: === | ||
* should %{__python26} be defined somewhere? in /etc/rpm/macros.python26 ? | * should %{__python26} be defined somewhere? in /etc/rpm/macros.python26 ? | ||
Revision as of 15:55, 13 September 2011
On EL5, the "system" python binary, /usr/bin/python is Python 2.4, and all add-on python packages are for the 2.4 syntax, and byte-compiled for 2.4.
EPEL5 provides a parallel-installable Python 2.6 stack. The core runtime is in the "python26" package, and there are a number of "python26-*" extension modules already in EPEL5.
Available Packages for EPEL5
- python26
- python26-devel
- python26-babel
- python26-dirq
- python26-distribute - fork of python-setuptools and provides the same functionality.
- python26-dns
- python26-gdata
- python26-greenlet
- python26-greenlet-devel
- python26-httplib2
- python26-imaging
- python26-imaging-devel
- python26-imaging-sane
- python26-imaging-tk
- python26-inotify
- python26-libs
- python26-markupsafe
- python26-mod_python
- python26-mod_wsgi
- python26-nose
- python26-pbs
- python26-PyXML
- python26-simplejson
- python26-sqlalchemy
- python26-test
- python26-tools
- python26-ZSI
Not Yet Available Packages for EPEL5
If you have interest towards some package, regardless are you pacakger or not, add it here if someone wants to package it.
- python26-cheetah - Template engine and code-generator (User:tuju, take src.rpm and maintain if you want.)
- python26-psycopg2 - A PostgreSQL database adapter for Python (bug 574586)
- python26-psycopg2-2.4 - A PostgreSQL database adapter for Python (User:tuju, take srpm / spec and maintain if you want.)
- python26-svgplotlib - Lightweight python package for creating SVG graphs and charts. (User:tuju,evaluation ongoing)
- python26-MySQL - MySQL Python bindings (User:tuju, take srpm / spec and maintain if you want.)
- python26-pytz
Packaging Guidelines for EPEL5
It is still under construction and content may change. Do not rely on the information on this page.
--Dmalcolm 20:48, 2 March 2011 (UTC): some python packages are provided as part of the RHEL5 product. Others are add-ons provided as part of EPEL5.
If you want a python26 version of a package that's already in RHEL5, I suggest creating a separate src.rpm, and filing a review request for it. It may also be good to locate the equivalent "python-" package within Fedora and do the following:
- Set up watchcommit on the Fedora package (and perhaps watch bugs)
- Add the maintainer to the CC on the package review
to help both of you maintain your respective packages.
If you want a python26 version of a package that's in EPEL5, you should also make a separate src.rpm. There are several reasons that the separate src.rpm is preferable in EPEL vs using the same src.rpm and separate subpackages.
- In EPEL, we're bound to keep backwards compat. However, people who want to deploy a python2.6 package are likely to want the latest and greatest versions of supporting python modules as well. Separate SRPMs gives us the flexibility, both at initial review, and if we decide we need to make an exception to upgrade something to an incompatible version in the future to do this for only the python2.6 package.
- Deploying as a subpackage is more limiting. If bugs exist on only one version of the python interpreter, we still have to update the module for both python-2.4 and python-2.6 which could be more churn for users or introduce unintentional new bugs on the other interpreter version. Similarly, if an update of a package is needed to fix a bug on one version of the interpreter but that update is known broken on the other version, you don't have the ability to update one but not the other.
Byte compiling
In Fedora, rpm has a byte compilation script that makes sure that python modules in their respective python*sitearch and python*sitelib directories are byte compiled with the correct version of python. In RHEL5, the byte compilation script uses the system python (python-2.4) for everything. To make byte compilation work, you need to override the script that's being used like this:
%global __os_install_post %__multiple_python_os_install_post
TODO:
- should %{__python26} be defined somewhere? in /etc/rpm/macros.python26 ?
Python26 Bugs in Bugzilla
References
- What’s New in Python 2.6
- #fedora-python26 irc channel in Freenode.