On 2016-04-26 09:14, Jan Rękorajski wrote:
You are probably breaking pypi and /usr/local installs again!
Proper directories for RPM packages are set with setup.py options via
%py_build/%py_install macros. Packages not using distutils/setuptools may
need patching, but that is better than breaking Python for non-RPM usage.
It caused distutils.sysconfig.get_python_lib() to return /usr/lib for
platform independent modules location which is not what we want and breaks
automake's python.m4.
I am sure I have left this for purpose. Many python packages, including
'core' ones, like setuptools/pip/virtualenv assume that python_lib is
${prefix}/lib. Things were quite broken when we patched Python to do
things 'the right way'.
We only need to force platform independent modules installed in
/usr/share when building RPM packages and that is mostly solved by our
%py_build/%py_install macros. The few packages left can always be patched.
That said… I have tested the python3 package after your change to find
what has been broken… and failed to get the expected results. Either I
cannot recall the exact thing broken (I have tested various pip and
virtualenv usage, using upstream packages) or this one change doesn't
break anything (the 'lib' is hardcoded in a similar way in a few places,
IIRC).
So it is possible that nothing have been broken in this case, but we
should be very careful about this.
virtualenv and pip _must_ work properly with unpatched upstream code for
/usr/local and $HOME installs – that is how lots of Python packages is
expected to be installed and we are not able to package everything
ourselves.
Jacek
_______________________________________________
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
