On 10/19/2018 01:22 PM, Stephen John Smoogen wrote:
Hi,
EPEL is a set of packages which work for CentOS and RHEL versions 6 and 7. In the version 7, we are currently using python34 and would like to move this to python36. In doing so, we need help in both our packaging rules and in updating a lot of packages to work for python36.
First problem: Packaging rules. Because there could be updates of python versions from 3.4 to 3.6 or 3.8, we wanted to make clear what python was used for any particular library. This would make it so someone needing python-bottle did not end up with one packaged with python-3.6 installed on a python-3.4 system. So we wanted the names to be more specific than python3 and went with naming all the sub packages python34 or python36.
However, this was decided a while ago and it may not be the best convention to use or one that the current python sig would like us to use. I would like to get a naming convention cleared up and documented so when we do a mass rebuild that the packages come out with either a python3-<foo> or python36-<foo>
If you are going to be having different versions of python3 over the life of a release, I think it's imperative that it be explicit what version of python 3 a package is for. Otherwise lies madness.
Second problem: When to do this update We had been looking to do this in October, but it may make more sense to do this in November after Fedora29 has shipped so that people can help focus on this versus anything F29 related. It also gives us some lead time to write blogs/magazine items. How does 2018-11-14 sound?
Third problem: Updating and rebuilding packages to work with python36
Below are the list of packages I found which were making python34-<libraryname> packages currently in EPEL-7. In updating to python36, I would like to have a combined Virtual Fedora Activity Day where we work together on IRC. First we would get any scripts ready and then work with release engineering to change macros in epel-macros to point to the correct versions of python and any name changes. We would then do a mass release bump and rebuild all the packages against python3.6. As problems are found during that day we would make appropriate changes and fix.
This might take 2 gos.
The biggest issue I have run into with Python 3 packaging in EPEL is version lock. Python modules (like most software) have atrocious backwards compatibility. For example, we have python3-scipy at version 0.18.1. If we add a python3_other_pkgversion package to it for python36, we get python36-scipy-0.18.1 whereas we really want python36-scipy-1.15.2 (not just to get the latest and greatest - though that is important - the old version of the module just may not work with the latest python). We can't update to that though in the python34 stack or we'll break things. This plays havock with the original vision of just flip a macro switch and rebuild everything, which means rolling out a new python version will take time and consideration of each package.
So I think we need another approach. Some ideas:
- Can we make epel7-py36 branches, and somehow have %python3_version, et. al. be 3.6 for those builds?
- Can we just make it easier for people to create python3X- packages from existing python3- or python3(X-n)- packages? And just drop the whole macro thing altogether, since sed -i -e s/pyton34-/python36-/ *.spec does 90% of the work?
Orion