On Wed, 2015-01-07 at 06:05 -0500, Bohuslav Kabrda wrote:
----- 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 [1] 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
>
> [1]
https://fedoraproject.org/wiki/User:Bkabrda/EPEL7_Python3
Let's reiterate:
- Nick Coghlan posted an interesting proposal to the discussion section in my proposal
(my reaction is in the blue frame) [1]. 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 question 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 important).
- 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 in 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 6 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 with
RHSCL. New collections from RHSCL will be named with "rh-" prefix and thus
won't conflict with python3X stacks.
Since it doesn't seem that there was anything very problematic, let's discuss 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 naming for
parallel stacks, but I believe we can discuss and solve these on the way.
A bikeshedding idea that may be controversial: aren't periods valid
characters within rpm package names? If so, can't we have the package
name be "python3.X" rather than "python3X". For that matter, dash
characters are valid in the name, so can't we call it "python-3.X"?
This might give e.g.
python-3.4-numpy-1.5.0-1.el7
^^^^^^^^^^^^^^^^ ^^^^^ ^^^^^
N V R
Though, for the core runtime e.g.
python-3.4-3.4.0-1.el7
might seem harder to read than:
python3.4-3.4.0-1.el7
or:
python34-3.4.0-1.el7
Apologies for the bikeshedding
Dave