Thank you for circling back on this. I was going to try and contact you today about python26 which is orphaned in EPEL-5 and was going to see if we could use the same logic for making a python27 tree for EL5 and EL6?
Yeah, theoretically we can do that, although I'm not very keen on the idea of maintaining yet another build of Python ;) certainly not for EPEL5...
Note, that one important thing to decide here what the dist-git solution will be. The EPEL5 python26 solution basically created new repos for all packages, called python26-*. That's viable for python27, since there's no python28 coming, but it's not a good solution for python3X. That's why I'd probably rather apply the same approach that we'll take for python3X in EPEL7 (whichever that will be).
Also, I'm starting to think about the technical solution (read: RPM macros) to multiple Pythons, since I really don't like the python26 solution from EPEL5. I'll put my solution in a proposal next week, so that everyone can comment on that, too.

Thanks,
Slavek

So here's a new part of the proposal that deals with specfiles/macros and how that all will work with imports from Fedora etc: https://fedoraproject.org/wiki/User:Bkabrda/EPEL7_Python3#Specfiles.2C_Macros.2C_Packaging_Process

Something similar should be usable in EPEL 6 for python27, but I realized that situation is a bit different, since python27 is never going to be replaced by python28, so there's no need to consider two 2X stacks. I have to admit that I have very little interest (and time!) for python27 in EPEL 6, so I'll leave that proposal to someone else.

As usual, all comments are appreciated!

Thanks,

Slavek