Proposed Mass Bug Filing: Python 3 Porting
Hello!
According to the Python packaging guidelines [*], software must be
packaged for Python 3 if upstream supports it. I would like to start
filing some cookie-cutter bugs [**] where that's not the case, or where
there are some common problems with the Python 3 porting.
Some people have already started doing this, especially during the
Fedora Activity Day (FAD) [***], but some of the bugs filed could be
clearer. Hopefully, going through the mass bug filing procedure will
raise the quality of these bug reports, and provide a single place to
track them.
This also means I don't have a list of packages this mass filing applies
to: usually where the issue is known, a bug was already filed. But many
more are surely left to report. Rumor has it that the next FAD is
already being planned; it would be nice to be ready for mass filing at
least by then.
Several different issues related to this are appearing in the wild. I'd
like to put them all under this umbrella, and I'm including bug report
text for each one below.
[*] https://fedoraproject.org/wiki/Packaging:Python
[**] https://fedoraproject.org/wiki/Mass_bug_filing
[***] https://fedoraproject.org/wiki/FAD_Python_3_Porting_2015
Proposed "Python 3 Porting Tracking bug" description:
"""
Bugs related to the Python 3 porting effort are tracked here. These are:
* No py3 subpackage where upstream supports py3
* No python2-* or python-* Provides
* Requires on both py2 and py3 in one RPM
Mass bug filing was discussed in <link> and announced in <link>
Python packaging guidelines: https://fedoraproject.org/wiki/Packaging:Python
"""
Proposed child bug titles and texts:
1. <name>: Provide a Python 3 subpackage
"""
Upstream, this software supports for Python 3. Please provide a Python 3
package for Fedora.
According to the Python packaging guidelines [0], software must be
packaged for Python 3 if upstream supports it.
The guidelines give detailed information on how to do this, and even
provide an example spec file [1].
The current best practice is to provide subpackages for the two Python
versions (called "Common SRPM" in the guidelines). Alternatively, if
nothing depends on your Python2 package, you can just switch to Python 3
entirely.
It's fine to do this in Rawhide only.
If anything is unclear, or if you need any kind of assistance with the
porting, you can ask on IRC (#fedora-python on Freenode), or reply here.
We'll be happy to help!
[0] https://fedoraproject.org/wiki/Packaging:Python
[1] https://fedoraproject.org/wiki/Packaging:Python#Example_common_spec_file
"""
2. <name>: Missing "python2-<module>" provide
"""
This package does not provide "python2-<module>".
As per Python packaging guidelines [0], when there are two versions of
module "foo", the two packages must provide:
"python3-foo" for Python 3
"python2-foo" for Python 2
"python-foo" for the system default Python (currently 2, but this might
change in the future)
Please use the %python_provide macro [1] to specify the correct provides.
It's fine to do this in Rawhide only.
If anything is unclear, or if you need any kind of assistance with this
issue, you can ask on IRC (#fedora-python on Freenode), or reply here.
We'll be happy to help!
[0] https://fedoraproject.org/wiki/Packaging:Python
[1]
https://fedoraproject.org/wiki/Packaging:Python#The_.25python_provide_macro
"""
3. <name>: Missing "python-<module>" provide
(as for 2., s/python2-/python-/ where necessary)
4. <name>: <RPM_name> requires both Python 2 and Python 3
"""
The <RPM_name> RPM requires both Python 2 and Python 3.
Except in very special circumstances, there is no need for one package
to drag in both Python stacks. Usually, this is a packaging error: for
example, a stray "/usr/bin/python" shebang in a Python 3 package can
introduce a Python 2 dependency.
Please split your package, or remove the stray dependencies.
It's fine to do this in Rawhide only.
If anything is unclear, or if you need any kind of assistance, you can
ask on IRC (#fedora-python on Freenode), or reply here. We'll be happy
to help investigating or fixing this issue!
"""
--
Petr Viktorin