On Sat, 13 Mar 2010 11:31:21 -0500
David Malcolm <dmalcolm(a)redhat.com> wrote:
On Sat, 2010-03-13 at 08:43 +0100, Steve Traylen wrote:
> On Sat, Mar 13, 2010 at 2:06 AM, Kevin Fenzi <kevin(a)tummy.com>
> > On Fri, 12 Mar 2010 19:40:05 -0500
> > David Malcolm <dmalcolm(a)redhat.com> wrote:
> >> I'm interested in maintaining a build of python 2.6 for EPEL5,
> >> parallel-installable with the system "python" (2.4 in EL5, which
> >> I comaintain within RHEL).
> > ...snip...
> >> Would people find this useful to have in EPEL5?
> > I personally would. We have several clients here that use a home
> > grown spec/rpm for this, and it would be great to have something
> > like this in the community. ;)
> > Whats the stance on modules for this python?
> > Similar to what we do for python3 in fedora? or forbidden?
> Certainly there is a follow up need for modules for this to be
> useful to the community. So copying python3 stance in Fedora makes
Re modules: very good point.
It's non-trivial to share modules directly between different minor
versions of python  - so it's simplest and safest to package up the
modules as "python26-foo" RPMs, rather than risk breaking the
What modules would people most want/need?
The ones that immediately spring to my mind are:
- a version of setuptools, since this needed by many builds; I would
choose the Distribute fork of setuptools, so probably I'd do a
- python26-nose.el5 (for tests, so that %check sections within
builds can be more robust)
- postgres and mysql connectivity, for the versions of those dbs
Are my instincts on the above correct; are those the ones that would
be most needed?
Yeah, we have various others that clients here use:
and probibly others.
I'm happy to package and maintain python26.el5 builds of the ones
listed above, assuming that people would find them useful.
Comaintainers welcome, of course.
From a packaging perspective, I can see two cases:
- packages that are maintained within EPEL. For these it may be
possible for the single python-foo.src.rpm to emit python-foo and
python26-foo subpackages in one build. This is similar to what we're
doing in Fedora with Python 3 support. This assumes that the
maintainer of that package cares about the 2.6 stack, and might
- packages that are maintained within RHEL/CentOS/etc. Given that
the python26 stack is in "downstream" EPEL rather than within the core
distribution, and conservatism within RHEL, for a given python-foo
src.rpm there would need to be a separate python26-foo.src.rpm (if
having one was desired), I think.
How does this sound?
Yeah, so we allow either one?