Thank you for circling back on this. I was going to try and contact
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.
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:
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!
I am very interested in python27 for EPEL5 and EPEL6 so will try to work on
those parts. While I don't expect a 28.. I will assume that someday someone
will make one even if it is Guido on April 1 2020.
epel-devel mailing list