On 24 February 2015 at 07:43, Bohuslav Kabrda <bkabrda@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


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