(Add bugzilla consideration for separate packages.) |
|||
(5 intermediate revisions by 3 users not shown) | |||
Line 1: | Line 1: | ||
{{autolang|base=yes}} | |||
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. | 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. | ||
Line 41: | Line 43: | ||
* python26-cheetah - Template engine and code-generator ([[User:tuju]], take [http://tuju.fi/centos/5/python26-cheetah-2.4.4-1.src.rpm src.rpm] and maintain if you want.) | * python26-cheetah - Template engine and code-generator ([[User:tuju]], take [http://tuju.fi/centos/5/python26-cheetah-2.4.4-1.src.rpm src.rpm] and maintain if you want.) | ||
* python26-psycopg2 - A PostgreSQL database adapter for Python ([https://bugzilla.redhat.com/show_bug.cgi?id=574586 bug 574586]) | * python26-psycopg2 - A PostgreSQL database adapter for Python ([https://bugzilla.redhat.com/show_bug.cgi?id=574586 bug 574586]) | ||
* python26-psycopg2-2.4 - A PostgreSQL database adapter for Python ([[User:tuju]], take [http://tuju.fi/centos/5/ srpm / spec] and maintain if you want.) | |||
* [http://code.google.com/p/svgplotlib/ python26-svgplotlib] - Lightweight python package for creating SVG graphs and charts. ([[User:tuju]],evaluation ongoing) | * [http://code.google.com/p/svgplotlib/ python26-svgplotlib] - Lightweight python package for creating SVG graphs and charts. ([[User:tuju]],evaluation ongoing) | ||
* python26-MySQL - MySQL Python bindings ([[User:tuju]], take [http://tuju.fi/centos/5/ srpm / spec] and maintain if you want.) | * python26-MySQL - MySQL Python bindings ([[User:tuju]], take [http://tuju.fi/centos/5/ srpm / spec] and maintain if you want.) | ||
* python26-pytz | |||
== Packaging Guidelines for EPEL5 == | == Packaging Guidelines for EPEL5 == | ||
Line 55: | Line 59: | ||
to help both of you maintain your respective packages. | to help both of you maintain your respective packages. | ||
If you want a python26 version of a package that's in EPEL5, | 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. | |||
* Since a large number of python modules (those with packages in RHEL) already need to have separate packages, figuring out where to place a bug in bugzilla is more difficult. For some packages a python-MODULE is the right place; other time a python26-MODULE is the right place. Keeping separate packages lets us standardize on python26-MODULE. | |||
=== 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 ? | ||
Latest revision as of 16:54, 7 December 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
--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.
- Since a large number of python modules (those with packages in RHEL) already need to have separate packages, figuring out where to place a bug in bugzilla is more difficult. For some packages a python-MODULE is the right place; other time a python26-MODULE is the right place. Keeping separate packages lets us standardize on python26-MODULE.
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.