Bug 1781940
| Summary: | Please branch and build python38 for EPEL 7 | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Jacob Floyd <cognifloyd> |
| Component: | python38 | Assignee: | Nobody <nobody> |
| Status: | CLOSED WONTFIX | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | rawhide | CC: | carl, cstratak, dmalcolm, kwizart, m.cyprian, mhroncok, pim, pviktori, python-sig, rkuska, shcherbina.iryna, slavek.kabrda, tomspur, torsava, vstinner |
| Target Milestone: | --- | Keywords: | FutureFeature |
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2020-12-21 11:36:51 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
Jacob Floyd
2019-12-10 22:30:44 UTC
Hi Jacob and thanks for the request. Unfortunately I am currently quite busy with maintaining the system python interpreter along with the alternative interpreters on various branches. I believe that would be the same for the rest of the python-sig members. Would you be willing to maintain the interpreter and keep it in good state for the epel7 branch? I am cc'ing Carl George as well, he might be interested into that, I understand he is quite busy as well though. I am not prepared to help with EPEL packaging. What kind of time commitment does it take to maintain a branch of python like this? A very long term commitment. Life time of EPEL is > decade, EPEL 7 will continue several years after Python 3.7 will been unsupported upstream. See the linked thread. This bug appears to have been reported against 'rawhide' during the Fedora 32 development cycle. Changing version to 32. For posterity, here are the EOL dates in question. 2021-12: Python 3.6 [0] 2023-06: Python 3.7 [0] 2024-06: RHEL 7 and EPEL 7 [1] 2024-10: Python 3.8 [2] 2029-05: RHEL 8 and EPEL 8 [1] Considering how the dates fall, and the fact that Red Hat will be maintaining python38 in RHEL 8 [3], I think it would make more sense to shift the spirit of this request from 3.7 to 3.8. This will be relatively straightforward once Miro's recent proposal on python-devel [4] is implemented. Would anyone be opposed to me transferring this bug to the python38 bugzilla component and changing the title? [0]: https://www.python.org/dev/peps/pep-0537/#lifespan [1]: https://access.redhat.com/support/policy/updates/errata#Life_Cycle_Dates [2]: https://www.python.org/dev/peps/pep-0569/#lifespan [3]: https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8-beta/html/8.2_release_notes/new-features#enhancement_dynamic-programming-languages-web-and-database-servers [4]: https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org/thread/5QUN7FWI6AV7BTMQGF257BEVMEA4QFOG/ If RHEL 8 already includes a Python 3.8 module, why would EPEL 8 need Python 3.8? > If RHEL 8 already includes a Python 3.8 module, why would EPEL 8 need Python 3.8?
This request is about EPEL 7.
python38 in EPEL 7 would satisfy me. (In reply to Carl George from comment #6) > For posterity, here are the EOL dates in question. > > 2021-12: Python 3.6 [0] > 2023-06: Python 3.7 [0] > 2024-06: RHEL 7 and EPEL 7 [1] > 2024-10: Python 3.8 [2] > 2029-05: RHEL 8 and EPEL 8 [1] > > Considering how the dates fall, and the fact that Red Hat will be > maintaining python38 in RHEL 8 [3], I think it would make more sense to > shift the spirit of this request from 3.7 to 3.8. I don't disagree with that, but I expect that more than trying to determine the "appropriate python version out of the Hat". My interpretation is that some end-users instead want a deterministic and reliable way to have "current" python on their enterprise OS. (even if with partial support or minimal/incomplete stack). So that end-users CI (or others uses-cases) can pick all ranges of python versions they want (like they can pick all ranges of PHP versions already , thanks Remi). As a Fedora maintainer, I would advertise to use Fedora with the appropriate python, then some Fedora versions might not be supported the same as the given python. For Enterprise users/needs, it would be easier to also have some python39 available at some point (only for EL8 as CentOS Stream/EPEL). (Side note, I'm just trying to "interpret" the request, not assume any resources to do the job in any way yet). Given the current state of things (e.g. Python 3.9 in ELN), may I suggest to repurpose this bugzilla for Python 3.9? I'd gladly help with the initial spec file, but if people want to build packages against Python 3.9/3.8, somebody else has to drive the Python 3.4 removal. I'm also afraid that if packagers simply start building from current EPEL 7 components, many ancient versions won't even support Python 3.9 (or 3.8). There is a rh-python38 available as scl, so I guess the issue can be closed. Please re-consider adding python38 to EPEL 7. Or at least uwsgi-plugin-python38 for compatibility with either rh-python38 or EPEL python38. |