On 13.8.2018 11:49, Larry Hastings wrote on python-dev@python.org:
We of the core dev community commit to supporting Python releases for five years. Releases get eighteen months of active bug fixes, followed by three and a half years of security fixes. Python 3.4 turns 5 next March--at which point we'll stop supporting it, and I'll retire as 3.4 release manager.
My plan is to make one final release on or around its fifth birthday containing the last round of security fixes. That's about seven months from now.
See also PEP 429 -- Python 3.4 Release Schedule [0].
We have python34 and python36 in EPEL7. python34 being the "main" one and python36 the "other" one. The original plan [1] was that once the ecosystem is adapted well enough, we can switch what "main" and "other" is and eventually drop python34, creating room for maybe another python3 release to be the "other" next (python38 maybe?). Originally this was supposed to happen for each release [2], but this was later abandoned due to lack of manpower.
Do we want to ever switch "main" with "other"? The problem here is:
$ dnf repoquery --repo=epel7 --whatrequires 'python(abi) = 3.4' | pkgname | sort | uniq | wc -l 243
$ dnf repoquery --repo=epel7 --whatrequires 'python(abi) = 3.6' | pkgname | sort | uniq | wc -l 15
The original idea is that all packages would have the python3_other macros in them [2] and all we need is rebuild everything in proper order, maybe with some bootstrapping. However that never happened and most of the packages I've seen lack the python3_other bits (no statistics, just my impression).
Is this something we want? If so, are the packagers willing to adapt their packages (as much as I'd like to do this, I lack the resources to hack on 228 packages)?
The Python Maint team in Red Hat is here to help. However the drive would need to come from the EPEL community, as now we are only guessing what are the needs here.
[0] https://www.python.org/dev/peps/pep-0429/ [1] https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject... [2] https://fedoraproject.org/wiki/User:Bkabrda/EPEL7_Python3
most of the packages I've seen lack the python3_other bits (no statistics, just my impression).
That's my impression too.
Is this something we want? If so, are the packagers willing to adapt their packages (as much as I'd like to do this, I lack the resources to hack on 228 packages)?
I've done quite a few but it's in the tens, not the hundreds. However, winter is coming and it's a nice activity when you're down with the flu.
I've noticed that the with_python3_other variable isn't defined in the file shipped by python3-rpm-macros, it would help transition to set that variable as in the original plan. The edits I've done use that variable as a conditional. Or shouldn't they?
I'm interesting in having more python3.6 packages in EPEL7 since newer releases of Mailman3 requires Python >= 3.5, so I'm currently stuck by some missing dependencies. So I'm willing to help move this forward.
Aurélien
On Tue, 2 Oct 2018 at 11:54, Aurelien Bompard abompard@fedoraproject.org wrote:
most of the packages I've seen lack the python3_other bits (no statistics, just my impression).
That's my impression too.
Is this something we want? If so, are the packagers willing to adapt their packages (as much as I'd like to do this, I lack the resources to hack on 228 packages)?
I've done quite a few but it's in the tens, not the hundreds. However, winter is coming and it's a nice activity when you're down with the flu.
I've noticed that the with_python3_other variable isn't defined in the file shipped by python3-rpm-macros, it would help transition to set that variable as in the original plan. The edits I've done use that variable as a conditional. Or shouldn't they?
I'm interesting in having more python3.6 packages in EPEL7 since newer releases of Mailman3 requires Python >= 3.5, so I'm currently stuck by some missing dependencies. So I'm willing to help move this forward.
So I would like to get this done in November after F29 is out the door. I am guessing a set of changes will be needed to be tested before hand.
python-devel@lists.fedoraproject.org
-
Aurelien Bompard -
Miro Hrončok -
Stephen John Smoogen