On Sat, 13 Mar 2010 11:31:21 -0500 David Malcolm <[email protected]> wrote:
> 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. 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
signature.asc
Description: PGP signature
_______________________________________________ epel-devel-list mailing list [email protected] https://www.redhat.com/mailman/listinfo/epel-devel-list
