[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Hoping to maintain python26 in EPEL5



On Sat, 2010-03-13 at 08:43 +0100, Steve Traylen wrote:
> On Sat, Mar 13, 2010 at 2:06 AM, Kevin Fenzi <kevin tummy com> wrote:
> > On Fri, 12 Mar 2010 19:40:05 -0500
> > David Malcolm <dmalcolm 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.  


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?

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.

I probably should say that although I'm sending this from an
"@redhat.com" address, none of this would be an official Red
Hat-supported part of RHEL 5.  I hope that eventually at least some of
it will be, but this is me as an individual contributor at this point[2]


>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?

Dave

[1] both compiled C extensions and compiled .pyc/.pyo bytecode files are
incompatible (but in both cases this is detectable, the former via the
"NEEDED" field in the ELF metadata, the latter via the magic number in
their header); see PEP 384 and PEP 3147 for future ideas towards being
able to share more, but they're not done yet.

[2] I use my @redhat.com address for all of the various FLOSS projects
that I'm involved in


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]