On Sat, 2010-03-13 at 08:43 +0100, Steve Traylen wrote: > On Sat, Mar 13, 2010 at 2:06 AM, Kevin Fenzi <[email protected]> wrote: > > On Fri, 12 Mar 2010 19:40:05 -0500 > > David Malcolm <[email protected]> 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 _______________________________________________ epel-devel-list mailing list [email protected] https://www.redhat.com/mailman/listinfo/epel-devel-list
