Hoping to maintain python26 in EPEL5

[Kevin Fenzi]

On Sat, 13 Mar 2010 11:31:21 -0500
David Malcolm <dmalcolm at 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 at tummy.com>
> > wrote:
> > > On Fri, 12 Mar 2010 19:40:05 -0500
> > > David Malcolm <dmalcolm at 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. ;)
> > Agreed.
> > > 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
> > sense.
> 
> Re modules: very good point.
> 
> It's non-trivial to share modules directly between different minor
> versions of python [1] - so it's simplest and safest to package up the
> modules as "python26-foo" RPMs, rather than risk breaking the "system"
> python stack.  

Yeah. ;) 

> 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-distribute-0.6.10.el5
> 
>   - 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
> within EL5
> 
> 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: 

mx
cracklib
pychecker
python-dateutil
python-xlrd

and probibly others. 

> I'm happy to package and maintain python26.el5 builds of the ones I
> listed above, assuming that people would find them useful.
> Comaintainers welcome, of course.

Cool. ;) 

> 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
> complicate specfiles.
>   - 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?

kevin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/epel-devel-list/attachments/20100314/73f66ff0/attachment.sig>