On 03/09/2018 07:25 AM, Petr Lautrbach wrote: > On Thu, Mar 08, 2018 at 10:19:26PM +0100, Nicolas Iooss wrote: >> On Thu, Mar 8, 2018 at 8:34 PM, Stephen Smalley <sds@xxxxxxxxxxxxx> wrote: >>> On 03/06/2018 04:19 PM, Stephen Smalley wrote: >>>> On 03/05/2018 05:16 PM, Nicolas Iooss wrote: >>>>> libselinux and libsemanage Makefiles invoke site.getsitepackages() in >>>>> order to get the path to the directory /usr/lib/pythonX.Y/site-packages >>>>> that matches the Python interpreter chosen with $(PYTHON). This method >>>>> is incompatible with Python virtual environments, as described in >>>>> https://github.com/pypa/virtualenv/issues/355#issuecomment-10250452 . >>>>> This issue has been opened for more than 5 years. >>>>> >>>>> On the contrary python/semanage/ and python/sepolgen/ Makefiles use >>>>> distutils.sysconfig.get_python_lib() in order to get the site-packages >>>>> path into a variable named PYTHONLIBDIR. This way of computing >>>>> PYTHONLIBDIR is compatible with virtual environments and gives the same >>>>> result as PYSITEDIR. >>>>> >>>>> As PYTHONLIBDIR works in more cases than PYSITEDIR, make libselinux and >>>>> libsemanage Makefiles use it. >>>> >>>> On Fedora x86_64, this changes the install location from /usr/lib64 to /usr/lib. >>> >>> That said I agree we ought to be consistent, and it does seem that we are not currently. >>> I'm just not sure what the best fix is in this case and the impact on distro packagers. >> >> Good point. I have read >> https://marc.info/?l=selinux&m=151670320132614&w=2 too quickly (and >> missed "given that there's only pure python modules"). This message >> suggests that doing using get_python_lib(plat_specific=1) would keep >> /usr/lib64 on Fedora (unfortunately I only have access to Debian, >> Ubuntu and Arch Linux systems right now so I am not able to test). > > On Fedora Rawhide: > >>>> get_python_lib() > '/usr/lib/python3.6/site-packages' >>>> get_python_lib(plat_specific=1) > '/usr/lib64/python3.6/site-packages' >>>> get_python_lib(prefix='/usr/local') > '/usr/local/lib/python3.6/site-packages' >>>> get_python_lib(prefix='/usr/local', plat_specific=1) > '/usr/local/lib64/python3.6/site-packages' > > >> And >> to be consistent, I suggest naming the variable differently from >> PYTHONLIBDIR. For example: >> >> PYTHONPLATLIBDIR ?= $(shell $(PYTHON) -c "from distutils.sysconfig >> import *; print(get_python_lib(plat_specific=1, prefix='$(PREFIX)'))") >> >> ... or PYPLATLIBDIR if PYTHONPLATLIBDIR is too long. Or we also can >> keep the name PYSITEDIR while changing its definition, in order to >> minimize the impact. What would be acceptable? >> > > Given that libselinux and libsemanage provides only extension SWIG generated > modules I'd just set plat_specific=1 and use PYTHONLIBDIR in this case. Looking at the Fedora packages (on 27), I see that: 1) libselinux-python{3} and libsemanage-python{3} puts all of their files under /usr/lib64 2) policycoreutils-python puts sepolicy under /usr/lib but the rest (e.g. seobject, sepolgen) under /usr/lib64 Meanwhile, a "make LIBDIR=/usr/lib64 SHLIBDIR=/lib64 install install-pywrap relabel" from selinux userspace (as per the README) installs the libselinux and libsemanage python modules under /usr/lib64 (the same as the Fedora packages) but all of the former policycoreutils ones (now python/*) under /usr/lib, and this seems to have been a change as part of Marcus' recent patch series (python: build: move modules from platform-specific to platform-shared). So is Fedora also going to move all of the policycoreutils-python modules to /usr/lib (maybe this has already happened in rawhide)?
