[EPEL-devel] Proposal for Python 3 packaging in EPEL 7

[Bohuslav Kabrda]

> > 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 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.fedoraproject.org/pipermail/epel-devel/attachments/20150115/9bbca562/attachment.html>