In line with the "Mass Python 2 Package Removal" Fedora 30 Change [0], we've just marked python2 and all it's subpackages as deprecated in rawhide [1].
No new packages can depend on python2 except renames and FESCo/FPC exceptions. See more info in the Guidelines for Deprecating Fedora Packages [2].
[0] https://fedoraproject.org/wiki/Changes/Mass_Python_2_Package_Removal [1] https://src.fedoraproject.org/rpms/python2/c/0052c9fa9d76e1706d96a17460ad26f... [2] https://fedoraproject.org/wiki/Packaging:Deprecating_Packages
Does this deprecation of python2 mean requests for package review with python2 only are now invalid?
For instance, I've asked upstream of pyVirtualize [+] for support of python3 [++]. Any patch to get pyvirtualize [+++] as a package to build with python3 is very welcome, though it's not the main job of us as downstream. If we can build with python3, I'll immediately remove the python2 part.
Regards, Raphael
[+] https://bugzilla.redhat.com/show_bug.cgi?id=1626231 [++] https://github.com/rocky1109/pyVirtualize/issues/3 [+++] https://raphgro.fedorapeople.org/review/py/pyvirtualize/pyvirtualize.spec
"RG" == Raphael Groner raphgro@fedoraproject.org writes:
RG> Does this deprecation of python2 mean requests for package review RG> with python2 only are now invalid?
Well they certainly shouldn't be approved; the idea of deprecating packages in this manner is to prevent the set of things which depend on them from growing.
If there's no hope of ever fixing the submitted packages to depend only on non-deprecated packages then I would guess they should be closed. Someone can always open a new ticket if the software is ported to python3.
- J<
On 7.9.2018 19:21, Raphael Groner wrote:
Does this deprecation of python2 mean requests for package review with python2 only are now invalid?
Yes. You can always get a FPC exception from (any) guideline or a FPC exemption from the review process, or a FESCo approved Change proposal, or cheat, but following the normal way of things, new packages that use python2 are not to be approved.
On Sun, Sep 9, 2018 at 2:29 PM Miro Hrončok mhroncok@redhat.com wrote:
On 7.9.2018 19:21, Raphael Groner wrote:
Does this deprecation of python2 mean requests for package review with python2 only are now invalid?
Yes. You can always get a FPC exception from (any) guideline or a FPC exemption from the review process, or a FESCo approved Change proposal, or cheat, but following the normal way of things, new packages that use python2 are not to be approved.
It's going to create some difficulties with porting leading edge python modules back to RHEL 7 or CentOS 7. The flexibility to enable python2 compilation, only, has been useful for me several times. Is there a timetable, or some guideline on when RHEL 8 is anticipated, so we'll be able to bring Fedora tested packages over to production.releases more easily?
On 9.9.2018 23:21, Nico Kadel-Garcia wrote:
On Sun, Sep 9, 2018 at 2:29 PM Miro Hrončok mhroncok@redhat.com wrote:
On 7.9.2018 19:21, Raphael Groner wrote:
Does this deprecation of python2 mean requests for package review with python2 only are now invalid?
Yes. You can always get a FPC exception from (any) guideline or a FPC exemption from the review process, or a FESCo approved Change proposal, or cheat, but following the normal way of things, new packages that use python2 are not to be approved.
It's going to create some difficulties with porting leading edge python modules back to RHEL 7 or CentOS 7. The flexibility to enable python2 compilation, only, has been useful for me several times.
Feel free to compile Python 2 stuff for you own testing on Fedora. Just don't put it in the repos. Use Python 3 in Fedora.
There's Python 3 in EPEL as well. I encourage you to use that.
If you'd like to have Python 3 in RHEL proper, use appropriate channels to request it, however there are already possibilities, see for example https://developers.redhat.com/blog/2018/08/13/install-python3-rhel/
(And I cannot answer you question.)
On Sun, Sep 9, 2018 at 6:00 PM Miro Hrončok mhroncok@redhat.com wrote:
On 9.9.2018 23:21, Nico Kadel-Garcia wrote:
On Sun, Sep 9, 2018 at 2:29 PM Miro Hrončok mhroncok@redhat.com wrote:
On 7.9.2018 19:21, Raphael Groner wrote:
Does this deprecation of python2 mean requests for package review with python2 only are now invalid?
Yes. You can always get a FPC exception from (any) guideline or a FPC exemption from the review process, or a FESCo approved Change proposal, or cheat, but following the normal way of things, new packages that use python2 are not to be approved.
It's going to create some difficulties with porting leading edge python modules back to RHEL 7 or CentOS 7. The flexibility to enable python2 compilation, only, has been useful for me several times.
Feel free to compile Python 2 stuff for you own testing on Fedora. Just don't put it in the repos. Use Python 3 in Fedora.
There's Python 3 in EPEL as well. I encourage you to use that.
If you'd like to have Python 3 in RHEL proper, use appropriate channels to request it, however there are already possibilities, see for example https://developers.redhat.com/blog/2018/08/13/install-python3-rhel/
(And I cannot answer you question.)
Fair enough. The EPEL publication of the "python34" and "python34-devel", etc. packages does not provide "python3" or "python3-devel" as packages, so the existing SRPM's from fedora would require significant customization to use that. I've worked extensively with the sclo python backages for RHEL and CentOS, As things stand, I've been able to rely on the default python2 for compilation there, which I understand is now deprecated. I'm not trying to say "don't deprecate python2", I'm saying "this is one of the immediate results that I, and others, will find awkward to spend time working around".
On 10.9.2018 05:07, Nico Kadel-Garcia wrote:
On Sun, Sep 9, 2018 at 6:00 PM Miro Hrončok mhroncok@redhat.com wrote:
On 9.9.2018 23:21, Nico Kadel-Garcia wrote:
On Sun, Sep 9, 2018 at 2:29 PM Miro Hrončok mhroncok@redhat.com wrote:
On 7.9.2018 19:21, Raphael Groner wrote:
Does this deprecation of python2 mean requests for package review with python2 only are now invalid?
Yes. You can always get a FPC exception from (any) guideline or a FPC exemption from the review process, or a FESCo approved Change proposal, or cheat, but following the normal way of things, new packages that use python2 are not to be approved.
It's going to create some difficulties with porting leading edge python modules back to RHEL 7 or CentOS 7. The flexibility to enable python2 compilation, only, has been useful for me several times.
Feel free to compile Python 2 stuff for you own testing on Fedora. Just don't put it in the repos. Use Python 3 in Fedora.
There's Python 3 in EPEL as well. I encourage you to use that.
If you'd like to have Python 3 in RHEL proper, use appropriate channels to request it, however there are already possibilities, see for example https://developers.redhat.com/blog/2018/08/13/install-python3-rhel/
(And I cannot answer you question.)
Fair enough. The EPEL publication of the "python34" and "python34-devel", etc. packages does not provide "python3" or "python3-devel" as packages, so the existing SRPM's from fedora would require significant customization to use that. I've worked extensively with the sclo python backages for RHEL and CentOS, As things stand, I've been able to rely on the default python2 for compilation there, which I understand is now deprecated. I'm not trying to say "don't deprecate python2", I'm saying "this is one of the immediate results that I, and others, will find awkward to spend time working around".
Let us know if you need help (with a specific problem you run into).
Just FTR current numbers about packages which requires python3 vs python2:
# dnf repoquery -C --whatrequires python3| grep -cv i686; dnf repoquery -C --whatrequires python2| grep -cv i686 Last metadata expiration check: 0:59:03 ago on Mon 10 Sep 2018 18:23:45 BST. 3034 Last metadata expiration check: 0:59:09 ago on Mon 10 Sep 2018 18:23:45 BST. 3415
In other words trying currently announcing python2 as depricated is at least a bit .. odd. kloczek
On 09/10/18 11:26, Tomasz Kłoczko wrote:
Just FTR current numbers about packages which requires python3 vs python2:
# dnf repoquery -C --whatrequires python3| grep -cv i686; dnf repoquery -C --whatrequires python2| grep -cv i686 Last metadata expiration check: 0:59:03 ago on Mon 10 Sep 2018 18:23:45 BST. 3034 Last metadata expiration check: 0:59:09 ago on Mon 10 Sep 2018 18:23:45 BST. 3415
These numbers hide an important fact: many things currently come with RPMs for both python2 and python3.
More detailed statistics (based on SRPMs, not binary RPMs): http://fedora.portingdb.xyz/ Graph with historical data: http://fedora.portingdb.xyz/history/
In other words trying currently announcing python2 as depricated is at least a bit .. odd. kloczek
Do you know a better way to make the python2 numbers go down?
Would *you* be interested in maintaining python2 past 2020, with no upstream support and 3415 dependent packages?
On Tue, 11 Sep 2018 at 16:48, Petr Viktorin pviktori@redhat.com wrote: [..]
These numbers hide an important fact: many things currently come with RPMs for both python2 and python3.
More detailed statistics (based on SRPMs, not binary RPMs): http://fedora.portingdb.xyz/ Graph with historical data: http://fedora.portingdb.xyz/history/
In other words trying currently announcing python2 as depricated is at least a bit .. odd.
Do you know a better way to make the python2 numbers go down?
Would *you* be interested in maintaining python2 past 2020, with no upstream support and 3415 dependent packages?
No and no .. of course :) I've been only trying to say that with current numbers about balance between python 2 and 3 packages are making announcement about deprecation a bit to early. Only this and nothing more :P I fully understand effort to migrate ASAP to python 3. IMO it should be announced only kind of call to migrate as much as possible with completing set of advises abut typical porting issues. Forming ad hoc team people which could help porting code to python 3 may IMO be useful.
I have in my set of packages one of those which will require migration to python 3 as well. It is mc package which has amazon s3 vfs backend as and I'm thinking about create mc-s3 (or mc-vfs-s3) subpackage to separate python2 dependent parts. Theoretically as now aws-cli AFAIK is already ported to python 3 it should be easy however I haven't now access to AWS systems to test s3 bucket access over mc. Other possible option may be rewrite s3 vfs backent to use some other (non python based script .. and backend tool).
kloczek
On 09/11/18 11:52, Tomasz Kłoczko wrote:
On Tue, 11 Sep 2018 at 16:48, Petr Viktorin <pviktori@redhat.com mailto:pviktori@redhat.com> wrote: [..]
These numbers hide an important fact: many things currently come with RPMs for both python2 and python3. More detailed statistics (based on SRPMs, not binary RPMs): http://fedora.portingdb.xyz/ Graph with historical data: http://fedora.portingdb.xyz/history/ > In other words trying currently announcing python2 as depricated is at > least a bit .. odd. Do you know a better way to make the python2 numbers go down? Would *you* be interested in maintaining python2 past 2020, with no upstream support and 3415 dependent packages?No and no .. of course :) I've been only trying to say that with current numbers about balance between python 2 and 3 packages are making announcement about deprecation a bit to early. Only this and nothing more :P
When will it not be too early?
I fully understand effort to migrate ASAP to python 3. IMO it should be announced only kind of call to migrate as much as possible with completing set of advises abut typical porting issues.
Python 3 is now almost 10 years old. The "Python 3 as Default" change was for Fedora 21. Python's documentation has a section on porting. There are printed books about porting. There's a comprehensive guide at portingguide.readthedocs.io. Fedora's Python packaging guidelines say "If it supports only python2 then [...] upstream SHOULD be contacted and encouraged to rectify this issue." -- have you done that?
We're honestly tired of making calls to migrate. What would another one of those accomplish?
Forming ad hoc team people which could help porting code to python 3 may IMO be useful.
Try the Python SIG!
I have in my set of packages one of those which will require migration to python 3 as well.
Why have you waited so long?
It is mc package which has amazon s3 vfs backend as and I'm thinking about create mc-s3 (or mc-vfs-s3) subpackage to separate python2 dependent parts. Theoretically as now aws-cli AFAIK is already ported to python 3 it should be easy however I haven't now access to AWS systems to test s3 bucket access over mc. Other possible option may be rewrite s3 vfs backent to use some other (non python based script .. and backend tool).
On Tue, 11 Sep 2018 at 23:38, Petr Viktorin pviktori@redhat.com wrote:
On 09/11/18 11:52, Tomasz Kłoczko wrote:
On Tue, 11 Sep 2018 at 16:48, Petr Viktorin <pviktori@redhat.com mailto:pviktori@redhat.com> wrote: [..]
These numbers hide an important fact: many things currently come with RPMs for both python2 and python3. More detailed statistics (based on SRPMs, not binary RPMs): http://fedora.portingdb.xyz/ Graph with historical data: http://fedora.portingdb.xyz/history/ > In other words trying currently announcing python2 as depricated is at > least a bit .. odd. Do you know a better way to make the python2 numbers go down? Would *you* be interested in maintaining python2 past 2020, with no upstream support and 3415 dependent packages?No and no .. of course :) I've been only trying to say that with current numbers about balance between python 2 and 3 packages are making announcement about deprecation a bit to early. Only this and nothing more :P
When will it not be too early?
IMO at least after porting to python 3 few crucial applications. One of the most important is gimp. Even more important would be getting rid of python 2 out of the @base and @core kickstart profiles.
Gimp has another tail in form of gtk+2 dependency but IMO cutting python 2 dependency is way simpler task. BTW: cutting off gtk+2 dependency is probably as same as python 2 important.
I fully understand effort to migrate ASAP to python 3.
IMO it should be announced only kind of call to migrate as much as possible with completing set of advises abut typical porting issues.
Python 3 is now almost 10 years old. The "Python 3 as Default" change was for Fedora 21. Python's documentation has a section on porting. There are printed books about porting. There's a comprehensive guide at portingguide.readthedocs.io. Fedora's Python packaging guidelines say "If it supports only python2 then [...] upstream SHOULD be contacted and encouraged to rectify this issue." -- have you done that?
We're honestly tired of making calls to migrate. What would another one of those accomplish?
Forming ad hoc team people which could help porting code to python 3 may IMO be useful.
Try the Python SIG!
Possibly .. however IMO python 2=>3 issues simple only massive and less complicated than ggenerally all python issues.
I have in my set of packages one of those which will require migration
to python 3 as well.
Why have you waited so long?
To have a bit more time to do this. Recently I've been a bit more busy and month ago started new contract in Brussels. Will try to do this probably in the end of this month (with add use more %lang() in mc.spec which I have in my own version of this file)
kloczek
Petr Viktorin wrote:
Would *you* be interested in maintaining python2 past 2020, with no upstream support and 3415 dependent packages?
Yet, I just see NO practical alternative to SOMEBODY doing just that. It just needs to be done, just as with GTK+ 1 and 2, and Qt 3 and 4. (Yes, all those are still in Fedora.)
We CANNOT just drop half of the distribution just because upstream arbitrarily decided to desupport its widely used language interpreter in favor of an incompatible new major version.
Kevin Kofler
On Sun, Sep 16, 2018 at 4:12 PM Kevin Kofler kevin.kofler@chello.at wrote:
We CANNOT just drop half of the distribution just because upstream arbitrarily decided to desupport its widely used language interpreter in favor of an incompatible new major version.
Well, to be fair the writing has been on the wall for Python ever since the release of 3.0 in 2008. With the sunset date of 2020 we're talking 12 years. Ultimately, it's the responsibility of upstream to do the migration. It's not like they haven't had plenty of notice. If upstream no longer cares, it's not practical for Fedora to accept the ongoing maintenance for these packages. That's just not realistic nor sustainable.
Miro Hrončok wrote:
[2] https://fedoraproject.org/wiki/Packaging:Deprecating_Packages
This policy is highly impractical. Any package can be deprecated without notice, in some situations even without any kind of approval (if there is nothing using it in Fedora yet). One needs to do a repoquery to even get the list of deprecated packages, because they are not centrally tracked. And if I package or review a new package, I am now supposed to check every single BuildRequires (and maybe also its transitive Requires closure?) for whether it "Provides: deprecated()"!? There is just no way I am going to do that.
Applying this policy to a language interpreter that is used by dozens of useful packages that are not yet packaged for Fedora makes it even more impractical. Let's face it: lots and lots of upstream software will NEVER be ported to Python 3. Yet, it is still useful, and may be the only way to do what the user needs to do. Banning all that software from Fedora is doing a major disservice to our users!
Kevin Kofler
-
Gerald B. Cox -
Jason L Tibbitts III -
Kevin Kofler -
Miro Hrončok -
Nico Kadel-Garcia -
Petr Viktorin -
Raphael Groner -
Tomasz Kłoczko