EPEL: Python 3.4 will be EOL in March 2019

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 13.8.2018 11:49, Larry Hastings wrote on python-dev@xxxxxxxxxx:
> 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@xxxxxxxxxxxxxxxxxxxxxxx/message/VLTFSZEQHXBZHHDAKMT4KCQEKPSFV5OS/
[2] https://fedoraproject.org/wiki/User:Bkabrda/EPEL7_Python3
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
_______________________________________________
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/message/WIDTOW7HUOJI3QO4WNCG2DTTF5B3CLBE/




[Index of Archives]     [Fedora Announce]     [Fedora News]     [Fedora Cloud]     [Fedora Advisory Board]     [Fedora Education]     [Fedora Security]     [Fedora Scitech]     [Fedora Robotics]     [Fedora Maintainers]     [Fedora Infrastructure]     [Fedora Websites]     [Anaconda Devel]     [Fedora Devel Java]     [Fedora Legacy]     [Fedora Desktop]     [Fedora Fonts]     [ATA RAID]     [Fedora Marketing]     [Fedora Management Tools]     [Fedora Mentors]     [Fedora Package Announce]     [SSH]     [Fedora Package Review]     [Fedora R Devel]     [Fedora PHP Devel]     [Kickstart]     [Fedora Music]     [Fedora Packaging]     [Centos]     [Fedora SELinux]     [Fedora Legal]     [Fedora Kernel]     [Fedora QA]     [Fedora Triage]     [Fedora OCaml]     [Coolkey]     [Virtualization Tools]     [ET Management Tools]     [Yum Users]     [Tux]     [Yosemite News]     [Linux Apps]     [Gnome Users]     [KDE Users]     [Fedora Tools]     [Fedora Art]     [Fedora Docs]     [Maemo Users]     [Asterisk PBX]     [Fedora Sparc]     [Fedora Universal Network Connector]     [Fedora ARM]

  Powered by Linux