On 7 January 2015 at 04:05, Bohuslav Kabrda < bkabrda(a)redhat.com
> ----- Original Message -----
> > Hi all,
> > I know I've been promising this for quite some time to several people, so
> > I
> > finally managed to put together a proposal for packaging Python 3 in EPEL
> > 7
> > (it'd also scale to EPEL 6 for that matter).
> > I've created a wiki page  with the proposal and I'd like to hear
> > comments
> > and thoughts on it. There are some TODOs and variants in few places - I'd
> > like to hear your opinions on these, or perhaps suggestions on better
> > approaches.
> > I'll create new documents with the updated proposal at some points during
> > the
> > discussion, so that people can easily see where the proposal is going
> > without having to compare wiki revisions.
> > Is there any other list/interested parties that should be put in CC of
> > this
> > mail? If so, please feel free to respond and do that yourself.
> > Thanks!
> > --
> > Regards,
> > Slavek Kabrda
> >  https://fedoraproject.org/wiki/User:Bkabrda/EPEL7_Python3
> Let's reiterate:
> - Nick Coghlan posted an interesting proposal to the discussion section in
> proposal (my reaction is in the blue frame) . I'd appreciate more
> comments on this.
> - From the feedback gathered on this list:
> - We should have /usr/bin/python3 pointing to a python3X build. The
> is which one this will be during transitional periods between 3X and 3X+1.
> My thinking is that we should point /usr/bin/python3 to 3X+1 at the time of
> retiring 3X (IMO there is no ideal time to do that, so it's not really
> - As for dist-git possibilities, Orion would prefer to use current dist-git
> repos with epel-7 branches. It's not my preference (for reasons mentioned
> the proposal), but I'm not against it if that is what others wish.
> - Stephen Smoogen mentioned that the transitional period during which
> python3X and python3X+1 exist can be anywhere from 6 weeks to 2 months. I'm
> starting to think that we should only specify the minimum time for which 3X
> will be kept. So my proposal would be sth. like "3X is kept for minimum of
> weeks in parallel to 3X+1. After this, it is retired as soon as all
> stakeholders have rebuilt against 3X+1." (keeping it a bit vague is a good
> thing here, I think)
> - As I noted in one of my emails, we don't have to worry about conflicts
> RHSCL. New collections from RHSCL will be named with "rh-" prefix and
> won't conflict with python3X stacks.
> Since it doesn't seem that there was anything very
> the points mentioned above after which I should be able to finalize the
> proposal and make it official (and then we could all get to building :)).
> I'm quite sure that we'll still hit some technical issues, e.g. macro
> for parallel stacks, but I believe we can discuss and solve these on the
Thank you for circling back on this. I was going to try and contact
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.
> Slavek Kabrda
Stephen J Smoogen.
epel-devel mailing list