[EPEL-devel] Python3x rpms (how do the IUS ones stack up with what we are looking for)

[Stephen John Smoogen]

On 24 February 2015 at 07:43, Bohuslav Kabrda <bkabrda at 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 at 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 at lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/epel-devel
>
>


-- 
Stephen J Smoogen.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.fedoraproject.org/pipermail/epel-devel/attachments/20150224/073d35f0/attachment.html>