https://fedoraproject.org/wiki/Changes/RetirePython2
== Summary == The {{package|python2}} package and all its subpackages will be removed from Fedora 32. A legacy {{package|python27}} package for developers and users will be provided. All packages in Fedora that need Python 2 to run will be removed from Fedora 32 regardless of their dependencies. All packages in Fedora that need Python 2 to build will be removed from Fedora 32 regardless of their dependencies. Exceptions can be granted by FESCo.
== Owner == * Name: [[User:Churchyard|Miro Hrončok]] * Email: mhroncok@redhat.com python-devel@lists.fedoraproject.org
== Detailed Description == Python 2 is unsupported upstream since 2020-01-01. Packages dependent on Python 2 are being removed from Fedora for several releases already:
* [[Changes/Mass_Python_2_Package_Removal|Fedora 30 Mass Python 2 Package Removal]] * [[Changes/F31_Mass_Python_2_Package_Removal|Fedora 31 Mass Python 2 Package Removal]]
Now, the Python maintainers have decided to pull the plug. The {{package|python2}} package and all its subpackages will be retired (read: removed) from Fedora 32 (Rawhide) as soon as Fedora 31 is branched.
All packages depending on any python2 package will be removed. The removal starts 2 weeks before the planned Fedora 32 Mass Rebuild. Broken dependencies will not stop the removals. Packages that Fail to Build From Source and prevent to remove Python 2 subpackages may end up with broken dependencies, in cases where it is not desired, those packages will be retired instead.
The rules also apply to modules built for Fedora 32+.
The package removal will be executed in an automated fashion.
Removed packages that would block the upgrades to Fedora 32 will be obsoleted from {{package|fedora-obsolete-packages}}.
=== The python27 package ===
Similarly to existing {{package|python36}}, {{package|python37}} etc. packages, a {{package|python27}} package will be created. This package is indented for Python developers who still need to support the legacy version of Python. This package is indented for users, who still need to use some software depending on the legacy version of Python. This package is not intended for other Fedora packages to be depended upon.
The {{package|python27}} package has several drawbacks compared to the original {{package|python2}} package:
* it is "flat" - there are no subpackages, everything lives in one package * there is no debug build (previously available as {{package|python2-debug}}) * there is no <code>/usr/bin/python</code> (note: there might be already the case before this change) * any special backwards compatible Provides are removed (this package is not intended to be depended upon)
=== FESCo exceptions ===
We realize that there are some packages whose removal could seriously hurt Fedora. FESCo can grant exceptions for packages to use the {{package|python27}} as a runtime or build dependency.
The package maintainer is responsible to check the entire dependency chain and they need to request exceptions for the entire list of packages. For example, when seeking exception for the {{package|chromium}} package, the request should contain {{package|python-psutil}} and other dependent packages. (Yes, this is tedious. Maintaining a Python 2 dependent package is a burden.)
The exception request must include a plan for migrating to Python 3.
Any non-essential dependency must be dropped. That includes optional dependencies, test dependencies, optional subpackages etc.
Package that fail to get an exception when the removal starts (see above) will be removed. Their importance for Fedora Release Engineering, Fedora Infrastructure or any other body will not be automagically respected; every package that needs Python 2 needs an exception.
The change owners will send regular reminders to the package owners.
== Benefit to Fedora == Python 2 is past upstream End of Life since 2020-01-01. This changes is generally crafted in a way that:
* it leaves Python developers an option to use it in case they still need to support it * it leaves Fedora users an option to use it in case they still need it to run their (3rd party) software * it leaves Fedora packagers an option to keep using it (complicated, but possible)
While:
* it removes Python 2 software from Fedora that was only preserved so far by inaction
Using Python 2 is dangerous. While the Fedora Python maintainers will try to fix as many security bugs as possible, without the upstream involvement this will be hard.
Python 2 is deprecated since Fedora 30. This change moves Python 2 from second class citizen to third class citizen.
== Scope == * Proposal owners: ** retire {{package|python2}} ** introduce {{package|python27}} ** remove all {{package|python2}} dependent packages that do not have FESCo exceptions ** obsolete removed packages that break the upgrade path via {{package|fedora-obsolete-packages}} * Other developers: ** remove their {{package|python2}} dependent packages without exceptions ** get exceptions if needed ** fix broken dependencies * Release engineering: [https://pagure.io/releng/issue/8306 #8306] easeBlocking/Fedora{{FedoraVersionNumber|next}}|List of deliverables]]: none * Policies and guidelines: Python 2 packaging is against the guidelines since Fedora 30. Python 2 packaging guidelines will be removed from [https://docs.fedoraproject.org/en-US/packaging-guidelines/Python_Appendix/ Python Appendix] (unless the FPC wants to keep them around until F31 EOL). * Trademark approval: not needed for this Change
== Upgrade/compatibility impact == The majority of removed packages will be obsoleted and removed on upgrade.
Users needing Python 2 libraries will not find these packaged as RPMs. They may install upstream versions using pip and virtualenv.
== How To Test == Try to update Fedora 30 or 31 to 32. No python2 packages should block the upgrade. Try to run Python 2 software via the {{package|python27}} package.
== User Experience == There will be close to zero Python 2 RPMs in Fedora repos. Users are encouraged to switch to Python 3 and/or use Python 2 virtual environments and pip for development.
== Dependencies == Ideally, all programs that use python2 would be switched to use python3. Although we don't expect everything to be switched over, as much as possible should be, so that the ripped remaining python2 set is small as possible.
== Contingency Plan == * Contingency mechanism: ** In case of serious issues, FESCo can issue a general exception for packages that would otherwise prevent Fedora 32 from being composed. ** If someone steps up to maintain Python 2 (including the full ecosystem of packages now in Fedora), they can decide to discontinue removing packages, revert this Change, or come up with another plan. (Note that in this case, current maintainers will most likely orphan many fundamental python2 packages.) * Contingency deadline: Fedora 32 Beta * Blocks release? in theory it should not, in practice, it may break the release and hence it will block it until fixed * Blocks product? all of them?
== Documentation == This page should serve as the documentation.
== Release Notes == TBD.
On 25. 04. 19 9:22, Miroslav Suchý wrote:
Dne 24. 04. 19 v 23:04 Ben Cotton napsal(a):
Removed packages that would block the upgrades to Fedora 32 will be obsoleted from {{package|fedora-obsolete-packages}}.
Which effectively means all python2-* packages. Right?
Almost. The ones that stop requiring the automatic provides and get FESCo exception to use python27 won't be obsoleted.
Note that only "problematic on upgrade" packages should be obsoleted, but anything that would require python(abi) = 2.7 or similar jumps to this category, so yes, probably all of them.
(I've previously forgot to reply to the list.)
On Thu, Apr 25, 2019 at 10:27 AM Miro Hrončok mhroncok@redhat.com wrote:
On 25. 04. 19 9:22, Miroslav Suchý wrote:
Dne 24. 04. 19 v 23:04 Ben Cotton napsal(a):
Removed packages that would block the upgrades to Fedora 32 will be obsoleted from {{package|fedora-obsolete-packages}}.
Which effectively means all python2-* packages. Right?
Almost. The ones that stop requiring the automatic provides and get FESCo exception to use python27 won't be obsoleted.
Note that only "problematic on upgrade" packages should be obsoleted, but anything that would require python(abi) = 2.7 or similar jumps to this category, so yes, probably all of them.
(I've previously forgot to reply to the list.)
How much is going to be needed for "mock" to still work for older operating systems? And for .spec files that may be backported to older Fedora or EPEL, do we want to have "with_python2" as a designated option to disable for Fedora > 31, but leave enabled for EPEL and older Fedora? I realize it's work similar to that of using "with_python3" up until now, but I'm not convinced we can gracefully abandon that altogether.
On 25. 04. 19 18:38, Nico Kadel-Garcia wrote:
On Thu, Apr 25, 2019 at 10:27 AM Miro Hrončok mhroncok@redhat.com wrote:
On 25. 04. 19 9:22, Miroslav Suchý wrote:
Dne 24. 04. 19 v 23:04 Ben Cotton napsal(a):
Removed packages that would block the upgrades to Fedora 32 will be obsoleted from {{package|fedora-obsolete-packages}}.
Which effectively means all python2-* packages. Right?
Almost. The ones that stop requiring the automatic provides and get FESCo exception to use python27 won't be obsoleted.
Note that only "problematic on upgrade" packages should be obsoleted, but anything that would require python(abi) = 2.7 or similar jumps to this category, so yes, probably all of them.
(I've previously forgot to reply to the list.)
How much is going to be needed for "mock" to still work for older operating systems?
I'm confused. How is the change relevant for mock? I think I'm missing some pieces of the thought process here, could you please elaborate on that?
And for .spec files that may be backported to older Fedora or EPEL, do we want to have "with_python2" as a designated option to disable for Fedora > 31, but leave enabled for EPEL and older Fedora?
%bcond_with python2 https://docs.fedoraproject.org/en-US/packaging-guidelines/Python_Appendix/#_...
I realize it's work similar to that of using "with_python3" up until now, but I'm not convinced we can gracefully abandon that altogether.
Abandon what exactly? with_python3? That of course depends on what operating systems you want the package to be built and the amount of your dependencies and their availability on EPEL7 for example. Msot "normal" stuff should be EPEL7-python3 compatible, for example mock (since you've mentioned it):
https://src.fedoraproject.org/rpms/mock/pull-request/6
On Thu, 2019-04-25 at 19:33 +0200, Miro Hrončok wrote:
On 25. 04. 19 18:38, Nico Kadel-Garcia wrote:
How much is going to be needed for "mock" to still work for older operating systems?
I'm confused. How is the change relevant for mock? I think I'm missing some pieces of the thought process here, could you please elaborate on that?
mock defaults to setting up buildroots for older OSes with yum, from the containing OS' side. yum is python2-only. So a py2-less host OS can't build for older OSes, without some finagling. In fact currently mock _defaults_ to yum, even for newer OSes, so removing python2 breaks mock's default invocation.
Vaguely related, there's no way to pass --yum or --dnf to fedpkg mockbuild. I've filed a bug about this, which has gotten no attention:
https://pagure.io/rpkg/issue/413
- ajax
On 25. 04. 19 20:33, Adam Jackson wrote:
On Thu, 2019-04-25 at 19:33 +0200, Miro Hrončok wrote:
On 25. 04. 19 18:38, Nico Kadel-Garcia wrote:
How much is going to be needed for "mock" to still work for older operating systems?
I'm confused. How is the change relevant for mock? I think I'm missing some pieces of the thought process here, could you please elaborate on that?
mock defaults to setting up buildroots for older OSes with yum, from the containing OS' side. yum is python2-only. So a py2-less host OS can't build for older OSes, without some finagling. In fact currently mock _defaults_ to yum, even for newer OSes, so removing python2 breaks mock's default invocation.
yum was already removed from Fedora 31. So removal of python2 doesn't change this, or does it?
On Thu, 2019-04-25 at 21:13 +0200, Miro Hrončok wrote:
On 25. 04. 19 20:33, Adam Jackson wrote:
On Thu, 2019-04-25 at 19:33 +0200, Miro Hrončok wrote:
On 25. 04. 19 18:38, Nico Kadel-Garcia wrote:
How much is going to be needed for "mock" to still work for older operating systems?
I'm confused. How is the change relevant for mock? I think I'm missing some pieces of the thought process here, could you please elaborate on that?
mock defaults to setting up buildroots for older OSes with yum, from the containing OS' side. yum is python2-only. So a py2-less host OS can't build for older OSes, without some finagling. In fact currently mock _defaults_ to yum, even for newer OSes, so removing python2 breaks mock's default invocation.
yum was already removed from Fedora 31. So removal of python2 doesn't change this, or does it?
I suppose removing python2 does not make it any _more_ broken, no.
- ajax
On Thu, 25 Apr 2019 at 13:35, Miro Hrončok mhroncok@redhat.com wrote:
On 25. 04. 19 18:38, Nico Kadel-Garcia wrote:
On Thu, Apr 25, 2019 at 10:27 AM Miro Hrončok mhroncok@redhat.com
wrote:
On 25. 04. 19 9:22, Miroslav Suchý wrote:
Dne 24. 04. 19 v 23:04 Ben Cotton napsal(a):
Removed packages that would block the upgrades to Fedora 32 will be obsoleted from {{package|fedora-obsolete-packages}}.
Which effectively means all python2-* packages. Right?
Almost. The ones that stop requiring the automatic provides and get
FESCo
exception to use python27 won't be obsoleted.
Note that only "problematic on upgrade" packages should be obsoleted,
but
anything that would require python(abi) = 2.7 or similar jumps to this
category,
so yes, probably all of them.
(I've previously forgot to reply to the list.)
How much is going to be needed for "mock" to still work for older operating systems?
I'm confused. How is the change relevant for mock? I think I'm missing some pieces of the thought process here, could you please elaborate on that?
In the past, changes where old versions of python were no longer supported in Fedora, then newer versions of mock/etc became dead in older OS's like RHEL-5's python24 and RHEL-6's python26. This would make compiling packages for certain versions of the OS impossible because the parent operating system didn't have a version of python it could use and you couldn't use newer source code on the older os.
The question is moot because you are the wrong person to ask. The person to ask is the owner of mock and I expect the answer will be... I don't have time to support N versions of python but you have the source code.. so do it yourself. [Probably nicer than that.. but the general effect.]
On 25. 04. 19 20:35, Stephen John Smoogen wrote:
> How much is going to be needed for "mock" to still work for older > operating systems? I'm confused. How is the change relevant for mock? I think I'm missing some pieces of the thought process here, could you please elaborate on that?
In the past, changes where old versions of python were no longer supported in Fedora, then newer versions of mock/etc became dead in older OS's like RHEL-5's python24 and RHEL-6's python26. This would make compiling packages for certain versions of the OS impossible because the parent operating system didn't have a version of python it could use and you couldn't use newer source code on the older os.
The question is moot because you are the wrong person to ask. The person to ask is the owner of mock and I expect the answer will be... I don't have time to support N versions of python but you have the source code.. so do it yourself. [Probably nicer than that.. but the general effect.]
mock in EPEL 6 is already "dead" in that matter:
https://bugzilla.redhat.com/show_bug.cgi?id=1694159
mock in EPEL 7 can run on Python 3.6:
https://src.fedoraproject.org/rpms/mock/pull-request/6
On Thu, Apr 25, 2019 at 3:20 PM Miro Hrončok mhroncok@redhat.com wrote:
On 25. 04. 19 20:35, Stephen John Smoogen wrote:
> How much is going to be needed for "mock" to still work for older > operating systems? I'm confused. How is the change relevant for mock? I think I'm missing some pieces of the thought process here, could you please elaborate on that?
In the past, changes where old versions of python were no longer supported in Fedora, then newer versions of mock/etc became dead in older OS's like RHEL-5's python24 and RHEL-6's python26. This would make compiling packages for certain versions of the OS impossible because the parent operating system didn't have a version of python it could use and you couldn't use newer source code on the older os.
The question is moot because you are the wrong person to ask. The person to ask is the owner of mock and I expect the answer will be... I don't have time to support N versions of python but you have the source code.. so do it yourself. [Probably nicer than that.. but the general effect.]
mock in EPEL 6 is already "dead" in that matter:
https://bugzilla.redhat.com/show_bug.cgi?id=1694159
mock in EPEL 7 can run on Python 3.6:
Which could make sense, but makes mock more awkward to install. I recognize that it's not Fedora's task to be completely compatible with RHEL, but it's an important downstream community to keep in mind. It's already making some work I do with Samba to activate domain controller features a bit more awkward.
On 26. 04. 19 3:08, Nico Kadel-Garcia wrote:
On Thu, Apr 25, 2019 at 3:20 PM Miro Hrončok mhroncok@redhat.com wrote:
On 25. 04. 19 20:35, Stephen John Smoogen wrote:
> How much is going to be needed for "mock" to still work for older > operating systems? I'm confused. How is the change relevant for mock? I think I'm missing some pieces of the thought process here, could you please elaborate on that?
In the past, changes where old versions of python were no longer supported in Fedora, then newer versions of mock/etc became dead in older OS's like RHEL-5's python24 and RHEL-6's python26. This would make compiling packages for certain versions of the OS impossible because the parent operating system didn't have a version of python it could use and you couldn't use newer source code on the older os.
The question is moot because you are the wrong person to ask. The person to ask is the owner of mock and I expect the answer will be... I don't have time to support N versions of python but you have the source code.. so do it yourself. [Probably nicer than that.. but the general effect.]
mock in EPEL 6 is already "dead" in that matter:
https://bugzilla.redhat.com/show_bug.cgi?id=1694159
mock in EPEL 7 can run on Python 3.6:
https://src.fedoraproject.org/rpms/mock/pull-request/6
Which could make sense, but makes mock more awkward to install.
How is that more awkward? The installation would still be be `yum install epel-release && yum install mock`.
On Fri, Apr 26, 2019 at 5:17 AM Miro Hrončok mhroncok@redhat.com wrote:
On 26. 04. 19 3:08, Nico Kadel-Garcia wrote:
On Thu, Apr 25, 2019 at 3:20 PM Miro Hrončok mhroncok@redhat.com wrote:
On 25. 04. 19 20:35, Stephen John Smoogen wrote:
> How much is going to be needed for "mock" to still work for older > operating systems? I'm confused. How is the change relevant for mock? I think I'm missing some pieces of the thought process here, could you please elaborate on that?
In the past, changes where old versions of python were no longer supported in Fedora, then newer versions of mock/etc became dead in older OS's like RHEL-5's python24 and RHEL-6's python26. This would make compiling packages for certain versions of the OS impossible because the parent operating system didn't have a version of python it could use and you couldn't use newer source code on the older os.
The question is moot because you are the wrong person to ask. The person to ask is the owner of mock and I expect the answer will be... I don't have time to support N versions of python but you have the source code.. so do it yourself. [Probably nicer than that.. but the general effect.]
mock in EPEL 6 is already "dead" in that matter:
https://bugzilla.redhat.com/show_bug.cgi?id=1694159
mock in EPEL 7 can run on Python 3.6:
https://src.fedoraproject.org/rpms/mock/pull-request/6
Which could make sense, but makes mock more awkward to install.
How is that more awkward? The installation would still be be `yum install epel-release && yum install mock`.
It brings in a distinct scripting language that is not part of the commercially supported base OS and makes the OS image for the server with mick installed notably larger. It's not *outrageous*, but it branches the tools for mock further from the base python on older, RHEL 7 systems. It adds support and places even more commoercial grade support on the EPEL repository.packages.
On Fri, Apr 26, 2019 at 8:09 AM Nico Kadel-Garcia nkadel@gmail.com wrote:
On Fri, Apr 26, 2019 at 5:17 AM Miro Hrončok mhroncok@redhat.com wrote:
On 26. 04. 19 3:08, Nico Kadel-Garcia wrote:
On Thu, Apr 25, 2019 at 3:20 PM Miro Hrončok mhroncok@redhat.com wrote:
On 25. 04. 19 20:35, Stephen John Smoogen wrote:
> How much is going to be needed for "mock" to still work for older > operating systems? I'm confused. How is the change relevant for mock? I think I'm missing some pieces of the thought process here, could you please elaborate on that?
In the past, changes where old versions of python were no longer supported in Fedora, then newer versions of mock/etc became dead in older OS's like RHEL-5's python24 and RHEL-6's python26. This would make compiling packages for certain versions of the OS impossible because the parent operating system didn't have a version of python it could use and you couldn't use newer source code on the older os.
The question is moot because you are the wrong person to ask. The person to ask is the owner of mock and I expect the answer will be... I don't have time to support N versions of python but you have the source code.. so do it yourself. [Probably nicer than that.. but the general effect.]
mock in EPEL 6 is already "dead" in that matter:
https://bugzilla.redhat.com/show_bug.cgi?id=1694159
mock in EPEL 7 can run on Python 3.6:
https://src.fedoraproject.org/rpms/mock/pull-request/6
Which could make sense, but makes mock more awkward to install.
How is that more awkward? The installation would still be be `yum install epel-release && yum install mock`.
It brings in a distinct scripting language that is not part of the commercially supported base OS and makes the OS image for the server with mick installed notably larger. It's not *outrageous*, but it branches the tools for mock further from the base python on older, RHEL 7 systems. It adds support and places even more commoercial grade support on the EPEL repository.packages.
Not for long. RHEL 7.7 is going to include Python 3 in the base: https://bugzilla.redhat.com/show_bug.cgi?id=1639030
And even if it wasn't, mock only exists in EPEL anyway, so we can consider EPEL dependencies for mock itself.
On Thu, 25 Apr 2019 at 08:34, Miroslav Suchý msuchy@redhat.com wrote:
Dne 24. 04. 19 v 23:04 Ben Cotton napsal(a):
Removed packages that would block the upgrades to Fedora 32 will be obsoleted from {{package|fedora-obsolete-packages}}.
Which effectively means all python2-* packages. Right?
And gimp or at least gimp python plugin .. as seem no one now at the moment is working to port that plugin to python 3.x https://gitlab.gnome.org/GNOME/gimp/commits/master?utf8=%E2%9C%93&search... https://gitlab.gnome.org/GNOME/gimp/branches/all?utf8=%E2%9C%93&search=p...
BTW: someone knows how often that python plugin is used? Someone here is using it or knows someone who uses it? (personally I think that it will be hard to find such person and packaging it is just kind of waste of effort)
kloczek
On 25. 04. 19 23:41, Tomasz Kłoczko wrote:
On Thu, 25 Apr 2019 at 08:34, Miroslav Suchý <msuchy@redhat.com mailto:msuchy@redhat.com> wrote:
Dne 24. 04. 19 v 23:04 Ben Cotton napsal(a): > Removed packages that would block the upgrades to Fedora 32 will be > obsoleted from {{package|fedora-obsolete-packages}}. Which effectively means all python2-* packages. Right?
And gimp or at least gimp python plugin .. as seem no one now at the moment is working to port that plugin to python 3.x https://gitlab.gnome.org/GNOME/gimp/commits/master?utf8=%E2%9C%93&search... https://gitlab.gnome.org/GNOME/gimp/branches/all?utf8=%E2%9C%93&search=p...
If the maintainers of gimp would like to keep it, they can request an exception.
GIMP is exactly one of the few things we had in mind when we decided to allow exceptions.