Hi,
those are very good questions to which you should be able to find
answers on the Python RPM Porting Guide [0]. You are right that this
should be better covered in the packaging guidelines, sadly the process
of changing them is rather problematic so no one yet had the time to
update them.
[0]
http://python-rpm-porting.readthedocs.io/en/latest/
Kind regards,
Tomas
On 05/26/2016 12:18 AM, John Dennis wrote:
With reference to the guidelines for Python packaging found here:
https://fedoraproject.org/wiki/Packaging:Python
Specifically the material concerning executables in /usr/bin.
In the "Example common spec file" section is this comment.
# Must do the python2 install first because the scripts in /usr/bin are
# overwritten with every setup.py install, and in general we want the
# python3 version to be the default.
But this does not work if you only install the python2-XXX package
instead of both the python2-XXX and python3-XXX packages. Here is why.
distutils will adjust the shbang interpreter line in installed scripts
to be interpreter specific, e.g. you get one of:
#!/usr/bin/python2
or
#!/usr/bin/python3
But the guidelines require the py3 version of the script in the py2
package. Thus if you install just the python2-XXX package you'll end
up with a script that runs the /usr/bin/python3 interpreter whose
sys.path only includes library locations for py3! Thus the script
cannot execute because it's missing its libraries (because the
libraries were installed in the py2 locations).
How is this supposed to be addressed?
One possible workaround is to add a requirement on the py3 package in
the py2 package. But that is silly because it completely negates
everything in the py2 package (everything will run as if it were py3
after installing the py2 package and the py2 files will never be
referenced).
Perhaps the issue is better rephrased as "How does one package Python
when there are no version specific differences/requirements?" If this
is covered in the guidelines it's not obvious and needs clarification.
I assume this means using the generic %{_python} macros instead of
dual use of the version specific macros so that everything corresponds
to the system default version of Python. Correct?