<html><body><div style="font-family: times new roman, new york, times, serif; font-size: 12pt; color: #000000"><blockquote style="border-left:2px solid #1010FF;margin-left:5px;padding-left:5px;color:#000;font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt;"><div><blockquote style="border-left:2px solid #1010FF;margin-left:5px;padding-left:5px;color:#000;font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt;"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>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? </div></div></div></div></blockquote><div>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...<br></div><div>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).<br></div><div>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.<br></div><div><br></div><div>Thanks,<br></div><div>Slavek</div></div></blockquote><div><br>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: <a href="https://fedoraproject.org/wiki/User:Bkabrda/EPEL7_Python3#Specfiles.2C_Macros.2C_Packaging_Process">https://fedoraproject.org/wiki/User:Bkabrda/EPEL7_Python3#Specfiles.2C_Macros.2C_Packaging_Process</a><br></div><div>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.<br></div><div>As usual, all comments are appreciated!<br></div><div><br></div><div>Thanks,<br></div><div>Slavek<br></div></div></body></html>