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

[Bohuslav Kabrda]

----- Original Message -----

> 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.

Yes, I have these assumptions as well. Python microreleases (3.4.microrelease) are bugfix only and upstream takes care to not break anything by them. BTW we do these updates in Fedora as well without actually rebuilding all depending packages, we just rely on upstream to do a good job maintaining stability - so far, they always did. 

> 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.

Well, I believe that the simplification is that people will be, initially, able to import their specs from Fedora with very few changes. 
Just BTW, I talked with Dennis Gilmore during DevConf and he said he's ok with putting the %python3_pkgversion_nodots and %python3_other_pkgversion_nodots macros into minimal buildroot in both Fedora and EPEL (Fedora will actually only have the first one), so this will provide additional simplification compared to my proposal for both packagers and for those during mass rebuild for new python3X+1. Also, I think I'll just strip the "_nodots" from macro names to make them look less awful :) 

Slavek 

> > Thanks,
> 
> > Slavek
> 

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