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
--
Orion Poplawski
Manager of NWRA Technical Systems 720-772-5637
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane orion@xxxxxxxx
Boulder, CO 80301 https://www.nwra.com/
_______________________________________________
epel-devel mailing list -- epel-devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to epel-devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@xxxxxxxxxxxxxxxxxxxxxxx
