> > 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
_______________________________________________ epel-devel mailing list [email protected] https://admin.fedoraproject.org/mailman/listinfo/epel-devel
