On 24 February 2015 at 07:43, Bohuslav Kabrda <bkabrda(a)redhat.com> wrote:
------------------------------
So I found that I had somehow gotten black holed on IUS emails and cleaned
that up today. In doing so I found they have an Python34u already in their
archives
http://dfw.mirror.rackspace.com/ius/stable/CentOS/7/SRPMS/
has a list of packages which they contain. I haven't looked too closely to
see how they match up with the current proposal.. or if they would pass a
fedora review yet. I wanted to bring them up as a strawman to look at for
reference to what Bohuslav Kabrda bkabrda(a)redhat.com had been aiming for
(in case it helps. If it doesn't.. disregard while I go get some more cough
medicine.)
--
Stephen J Smoogen.
Thanks for the link, this actually looks very similar to what I'm planning
to do with my proposal, although I think it doesn't handle parallel
python3X and python3X+1 stacks. As you suggested in the other email, I'll
try to build a proof of concept minimal python34 stack with several
packages (in Copr, most likely) and post it here for testing and comments.
If everything looks good, I'll start pushing it to EPEL after that.
Correct. I had an irc conversation with one of their devs, and I believe
they have the following assumptions:
1) A python3X is the only one that will be installed at a time.
2) A python3X is not stuck at 3.4.5 say, but would be upgraded to 3.4.6
when 3.4.6 came out.
3) A python3x-mailman that was built against 3.4.2 would not be rebuilt if
you went to 3.4.6 as an update unless it was found that it needed to be.
Do those simplifications make your life easier as a packager? What
difficulties does it make for others. [Does saying "We don't support
parallel python3X python3X+1" and if you want that use SCL's.. a problem?]
I am asking this on a bunch of cold medicine so if the answer is obvious
that it is unacceptable sorry for missing it.
Thanks,
Slavek
_______________________________________________
epel-devel mailing list
epel-devel(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/epel-devel
--
Stephen J Smoogen.