Discussion:
[PATCH 1/1] libselinux,
Nicolas Iooss
2018-03-05 22:16:11 UTC
Permalink
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.

Signed-off-by: Nicolas Iooss <***@m4x.org>
---
.travis.yml | 5 +----
libselinux/src/Makefile | 10 +++++-----
libsemanage/src/Makefile | 8 ++++----
3 files changed, 10 insertions(+), 13 deletions(-)

diff --git a/.travis.yml b/.travis.yml
index 0312e996e333..63c7a544aa45 100644
--- a/.travis.yml
+++ b/.travis.yml
@@ -96,9 +96,6 @@ before_script:
- export PKG_CONFIG_PATH="/opt/python/$($PYTHON -c 'import sys;print("%d.%d.%d" % sys.version_info[:3])')/lib/pkgconfig"
# PyPy does not provide a config file for pkg-config nor a pypy-c.so
- if echo "$PYVER" | grep -q pypy ; then export PYINC=-I$($PYTHON -c 'import sys;print(sys.prefix)')/include PYLIBS= ; fi
- # Python virtualenvs do not support "import site; print(site.getsitepackages()[0]"
- # cf. https://github.com/pypa/virtualenv/issues/355#issuecomment-10250452
- - export PYSITEDIR="/usr/lib/$($PYTHON -c 'import sys;print("python%d.%d" % sys.version_info[:2])')/site-packages"

# Find the Ruby executable with version $RUBYLIBVER
- export RUBY="$(ls -d -1 "$HOME/.rvm/rubies/ruby-$RUBYLIBVER"*/bin/ruby | head -n 1)"
@@ -126,7 +123,7 @@ script:
# Set up environment variables for the tests
- export LD_LIBRARY_PATH="$DESTDIR/usr/lib:$DESTDIR/lib"
- export PATH="$DESTDIR/usr/sbin:$DESTDIR/usr/bin:$DESTDIR/sbin:$DESTDIR/bin:$PATH"
- - export PYTHONPATH="$DESTDIR$PYSITEDIR"
+ - export PYTHONPATH="$DESTDIR$($PYTHON -c "from distutils.sysconfig import *;print(get_python_lib(prefix='/usr'))")"
- export RUBYLIB="$DESTDIR/$($RUBY -e 'puts RbConfig::CONFIG["vendorlibdir"]'):$DESTDIR/$($RUBY -e 'puts RbConfig::CONFIG["vendorarchdir"]')"

# Show variables (to help debugging issues)
diff --git a/libselinux/src/Makefile b/libselinux/src/Makefile
index 18588da586bf..ff55680e384a 100644
--- a/libselinux/src/Makefile
+++ b/libselinux/src/Makefile
@@ -14,7 +14,7 @@ SHLIBDIR ?= /lib
INCLUDEDIR ?= $(PREFIX)/include
PYINC ?= $(shell $(PKG_CONFIG) --cflags $(PYPREFIX))
PYLIBS ?= $(shell $(PKG_CONFIG) --libs $(PYPREFIX))
-PYSITEDIR ?= $(shell $(PYTHON) -c 'import site; print(site.getsitepackages()[0])')
+PYTHONLIBDIR ?= $(shell $(PYTHON) -c "from distutils.sysconfig import *; print(get_python_lib(prefix='$(PREFIX)'))")
PYCEXT ?= $(shell $(PYTHON) -c 'import imp;print([s for s,m,t in imp.get_suffixes() if t == imp.C_EXTENSION][0])')
RUBYINC ?= $(shell $(RUBY) -e 'puts "-I" + RbConfig::CONFIG["rubyarchhdrdir"] + " -I" + RbConfig::CONFIG["rubyhdrdir"]')
RUBYLIBS ?= $(shell $(RUBY) -e 'puts "-L" + RbConfig::CONFIG["libdir"] + " -L" + RbConfig::CONFIG["archlibdir"] + " " + RbConfig::CONFIG["LIBRUBYARG_SHARED"]')
@@ -191,10 +191,10 @@ install: all
ln -sf --relative $(DESTDIR)$(SHLIBDIR)/$(LIBSO) $(DESTDIR)$(LIBDIR)/$(TARGET)

install-pywrap: pywrap
- test -d $(DESTDIR)$(PYSITEDIR)/selinux || install -m 755 -d $(DESTDIR)$(PYSITEDIR)/selinux
- install -m 755 $(SWIGSO) $(DESTDIR)$(PYSITEDIR)/_selinux$(PYCEXT)
- install -m 755 $(AUDIT2WHYSO) $(DESTDIR)$(PYSITEDIR)/selinux/audit2why$(PYCEXT)
- install -m 644 $(SWIGPYOUT) $(DESTDIR)$(PYSITEDIR)/selinux/__init__.py
+ test -d $(DESTDIR)$(PYTHONLIBDIR)/selinux || install -m 755 -d $(DESTDIR)$(PYTHONLIBDIR)/selinux
+ install -m 755 $(SWIGSO) $(DESTDIR)$(PYTHONLIBDIR)/_selinux$(PYCEXT)
+ install -m 755 $(AUDIT2WHYSO) $(DESTDIR)$(PYTHONLIBDIR)/selinux/audit2why$(PYCEXT)
+ install -m 644 $(SWIGPYOUT) $(DESTDIR)$(PYTHONLIBDIR)/selinux/__init__.py

install-rubywrap: rubywrap
test -d $(DESTDIR)$(RUBYINSTALL) || install -m 755 -d $(DESTDIR)$(RUBYINSTALL)
diff --git a/libsemanage/src/Makefile b/libsemanage/src/Makefile
index e98d8760acb7..bcee93b36977 100644
--- a/libsemanage/src/Makefile
+++ b/libsemanage/src/Makefile
@@ -13,7 +13,7 @@ LIBDIR ?= $(PREFIX)/lib
INCLUDEDIR ?= $(PREFIX)/include
PYINC ?= $(shell $(PKG_CONFIG) --cflags $(PYPREFIX))
PYLIBS ?= $(shell $(PKG_CONFIG) --libs $(PYPREFIX))
-PYSITEDIR ?= $(shell $(PYTHON) -c 'import site; print(site.getsitepackages()[0])')
+PYTHONLIBDIR ?= $(shell $(PYTHON) -c "from distutils.sysconfig import *; print(get_python_lib(prefix='$(PREFIX)'))")
PYCEXT ?= $(shell $(PYTHON) -c 'import imp;print([s for s,m,t in imp.get_suffixes() if t == imp.C_EXTENSION][0])')
RUBYINC ?= $(shell $(RUBY) -e 'puts "-I" + RbConfig::CONFIG["rubyarchhdrdir"] + " -I" + RbConfig::CONFIG["rubyhdrdir"]')
RUBYLIBS ?= $(shell $(RUBY) -e 'puts "-L" + RbConfig::CONFIG["libdir"] + " -L" + RbConfig::CONFIG["archlibdir"] + " " + RbConfig::CONFIG["LIBRUBYARG_SHARED"]')
@@ -142,9 +142,9 @@ install: all
cd $(DESTDIR)$(LIBDIR) && ln -sf $(LIBSO) $(TARGET)

install-pywrap: pywrap
- test -d $(DESTDIR)$(PYSITEDIR) || install -m 755 -d $(DESTDIR)$(PYSITEDIR)
- install -m 755 $(SWIGSO) $(DESTDIR)$(PYSITEDIR)/_semanage$(PYCEXT)
- install -m 644 semanage.py $(DESTDIR)$(PYSITEDIR)
+ test -d $(DESTDIR)$(PYTHONLIBDIR) || install -m 755 -d $(DESTDIR)$(PYTHONLIBDIR)
+ install -m 755 $(SWIGSO) $(DESTDIR)$(PYTHONLIBDIR)/_semanage$(PYCEXT)
+ install -m 644 semanage.py $(DESTDIR)$(PYTHONLIBDIR)


install-rubywrap: rubywrap
--
2.16.0
Stephen Smalley
2018-03-06 21:19:33 UTC
Permalink
Post by Nicolas Iooss
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.
Post by Nicolas Iooss
---
.travis.yml | 5 +----
libselinux/src/Makefile | 10 +++++-----
libsemanage/src/Makefile | 8 ++++----
3 files changed, 10 insertions(+), 13 deletions(-)
diff --git a/.travis.yml b/.travis.yml
index 0312e996e333..63c7a544aa45 100644
--- a/.travis.yml
+++ b/.travis.yml
- export PKG_CONFIG_PATH="/opt/python/$($PYTHON -c 'import sys;print("%d.%d.%d" % sys.version_info[:3])')/lib/pkgconfig"
# PyPy does not provide a config file for pkg-config nor a pypy-c.so
- if echo "$PYVER" | grep -q pypy ; then export PYINC=-I$($PYTHON -c 'import sys;print(sys.prefix)')/include PYLIBS= ; fi
- # Python virtualenvs do not support "import site; print(site.getsitepackages()[0]"
- # cf. https://github.com/pypa/virtualenv/issues/355#issuecomment-10250452
- - export PYSITEDIR="/usr/lib/$($PYTHON -c 'import sys;print("python%d.%d" % sys.version_info[:2])')/site-packages"
# Find the Ruby executable with version $RUBYLIBVER
- export RUBY="$(ls -d -1 "$HOME/.rvm/rubies/ruby-$RUBYLIBVER"*/bin/ruby | head -n 1)"
# Set up environment variables for the tests
- export LD_LIBRARY_PATH="$DESTDIR/usr/lib:$DESTDIR/lib"
- export PATH="$DESTDIR/usr/sbin:$DESTDIR/usr/bin:$DESTDIR/sbin:$DESTDIR/bin:$PATH"
- - export PYTHONPATH="$DESTDIR$PYSITEDIR"
+ - export PYTHONPATH="$DESTDIR$($PYTHON -c "from distutils.sysconfig import *;print(get_python_lib(prefix='/usr'))")"
- export RUBYLIB="$DESTDIR/$($RUBY -e 'puts RbConfig::CONFIG["vendorlibdir"]'):$DESTDIR/$($RUBY -e 'puts RbConfig::CONFIG["vendorarchdir"]')"
# Show variables (to help debugging issues)
diff --git a/libselinux/src/Makefile b/libselinux/src/Makefile
index 18588da586bf..ff55680e384a 100644
--- a/libselinux/src/Makefile
+++ b/libselinux/src/Makefile
@@ -14,7 +14,7 @@ SHLIBDIR ?= /lib
INCLUDEDIR ?= $(PREFIX)/include
PYINC ?= $(shell $(PKG_CONFIG) --cflags $(PYPREFIX))
PYLIBS ?= $(shell $(PKG_CONFIG) --libs $(PYPREFIX))
-PYSITEDIR ?= $(shell $(PYTHON) -c 'import site; print(site.getsitepackages()[0])')
+PYTHONLIBDIR ?= $(shell $(PYTHON) -c "from distutils.sysconfig import *; print(get_python_lib(prefix='$(PREFIX)'))")
PYCEXT ?= $(shell $(PYTHON) -c 'import imp;print([s for s,m,t in imp.get_suffixes() if t == imp.C_EXTENSION][0])')
RUBYINC ?= $(shell $(RUBY) -e 'puts "-I" + RbConfig::CONFIG["rubyarchhdrdir"] + " -I" + RbConfig::CONFIG["rubyhdrdir"]')
RUBYLIBS ?= $(shell $(RUBY) -e 'puts "-L" + RbConfig::CONFIG["libdir"] + " -L" + RbConfig::CONFIG["archlibdir"] + " " + RbConfig::CONFIG["LIBRUBYARG_SHARED"]')
@@ -191,10 +191,10 @@ install: all
ln -sf --relative $(DESTDIR)$(SHLIBDIR)/$(LIBSO) $(DESTDIR)$(LIBDIR)/$(TARGET)
install-pywrap: pywrap
- test -d $(DESTDIR)$(PYSITEDIR)/selinux || install -m 755 -d $(DESTDIR)$(PYSITEDIR)/selinux
- install -m 755 $(SWIGSO) $(DESTDIR)$(PYSITEDIR)/_selinux$(PYCEXT)
- install -m 755 $(AUDIT2WHYSO) $(DESTDIR)$(PYSITEDIR)/selinux/audit2why$(PYCEXT)
- install -m 644 $(SWIGPYOUT) $(DESTDIR)$(PYSITEDIR)/selinux/__init__.py
+ test -d $(DESTDIR)$(PYTHONLIBDIR)/selinux || install -m 755 -d $(DESTDIR)$(PYTHONLIBDIR)/selinux
+ install -m 755 $(SWIGSO) $(DESTDIR)$(PYTHONLIBDIR)/_selinux$(PYCEXT)
+ install -m 755 $(AUDIT2WHYSO) $(DESTDIR)$(PYTHONLIBDIR)/selinux/audit2why$(PYCEXT)
+ install -m 644 $(SWIGPYOUT) $(DESTDIR)$(PYTHONLIBDIR)/selinux/__init__.py
install-rubywrap: rubywrap
test -d $(DESTDIR)$(RUBYINSTALL) || install -m 755 -d $(DESTDIR)$(RUBYINSTALL)
diff --git a/libsemanage/src/Makefile b/libsemanage/src/Makefile
index e98d8760acb7..bcee93b36977 100644
--- a/libsemanage/src/Makefile
+++ b/libsemanage/src/Makefile
@@ -13,7 +13,7 @@ LIBDIR ?= $(PREFIX)/lib
INCLUDEDIR ?= $(PREFIX)/include
PYINC ?= $(shell $(PKG_CONFIG) --cflags $(PYPREFIX))
PYLIBS ?= $(shell $(PKG_CONFIG) --libs $(PYPREFIX))
-PYSITEDIR ?= $(shell $(PYTHON) -c 'import site; print(site.getsitepackages()[0])')
+PYTHONLIBDIR ?= $(shell $(PYTHON) -c "from distutils.sysconfig import *; print(get_python_lib(prefix='$(PREFIX)'))")
PYCEXT ?= $(shell $(PYTHON) -c 'import imp;print([s for s,m,t in imp.get_suffixes() if t == imp.C_EXTENSION][0])')
RUBYINC ?= $(shell $(RUBY) -e 'puts "-I" + RbConfig::CONFIG["rubyarchhdrdir"] + " -I" + RbConfig::CONFIG["rubyhdrdir"]')
RUBYLIBS ?= $(shell $(RUBY) -e 'puts "-L" + RbConfig::CONFIG["libdir"] + " -L" + RbConfig::CONFIG["archlibdir"] + " " + RbConfig::CONFIG["LIBRUBYARG_SHARED"]')
@@ -142,9 +142,9 @@ install: all
cd $(DESTDIR)$(LIBDIR) && ln -sf $(LIBSO) $(TARGET)
install-pywrap: pywrap
- test -d $(DESTDIR)$(PYSITEDIR) || install -m 755 -d $(DESTDIR)$(PYSITEDIR)
- install -m 755 $(SWIGSO) $(DESTDIR)$(PYSITEDIR)/_semanage$(PYCEXT)
- install -m 644 semanage.py $(DESTDIR)$(PYSITEDIR)
+ test -d $(DESTDIR)$(PYTHONLIBDIR) || install -m 755 -d $(DESTDIR)$(PYTHONLIBDIR)
+ install -m 755 $(SWIGSO) $(DESTDIR)$(PYTHONLIBDIR)/_semanage$(PYCEXT)
+ install -m 644 semanage.py $(DESTDIR)$(PYTHONLIBDIR)
install-rubywrap: rubywrap
Stephen Smalley
2018-03-08 19:34:35 UTC
Permalink
Post by Stephen Smalley
Post by Nicolas Iooss
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.
Post by Stephen Smalley
Post by Nicolas Iooss
---
.travis.yml | 5 +----
libselinux/src/Makefile | 10 +++++-----
libsemanage/src/Makefile | 8 ++++----
3 files changed, 10 insertions(+), 13 deletions(-)
diff --git a/.travis.yml b/.travis.yml
index 0312e996e333..63c7a544aa45 100644
--- a/.travis.yml
+++ b/.travis.yml
- export PKG_CONFIG_PATH="/opt/python/$($PYTHON -c 'import sys;print("%d.%d.%d" % sys.version_info[:3])')/lib/pkgconfig"
# PyPy does not provide a config file for pkg-config nor a pypy-c.so
- if echo "$PYVER" | grep -q pypy ; then export PYINC=-I$($PYTHON -c 'import sys;print(sys.prefix)')/include PYLIBS= ; fi
- # Python virtualenvs do not support "import site; print(site.getsitepackages()[0]"
- # cf. https://github.com/pypa/virtualenv/issues/355#issuecomment-10250452
- - export PYSITEDIR="/usr/lib/$($PYTHON -c 'import sys;print("python%d.%d" % sys.version_info[:2])')/site-packages"
# Find the Ruby executable with version $RUBYLIBVER
- export RUBY="$(ls -d -1 "$HOME/.rvm/rubies/ruby-$RUBYLIBVER"*/bin/ruby | head -n 1)"
# Set up environment variables for the tests
- export LD_LIBRARY_PATH="$DESTDIR/usr/lib:$DESTDIR/lib"
- export PATH="$DESTDIR/usr/sbin:$DESTDIR/usr/bin:$DESTDIR/sbin:$DESTDIR/bin:$PATH"
- - export PYTHONPATH="$DESTDIR$PYSITEDIR"
+ - export PYTHONPATH="$DESTDIR$($PYTHON -c "from distutils.sysconfig import *;print(get_python_lib(prefix='/usr'))")"
- export RUBYLIB="$DESTDIR/$($RUBY -e 'puts RbConfig::CONFIG["vendorlibdir"]'):$DESTDIR/$($RUBY -e 'puts RbConfig::CONFIG["vendorarchdir"]')"
# Show variables (to help debugging issues)
diff --git a/libselinux/src/Makefile b/libselinux/src/Makefile
index 18588da586bf..ff55680e384a 100644
--- a/libselinux/src/Makefile
+++ b/libselinux/src/Makefile
@@ -14,7 +14,7 @@ SHLIBDIR ?= /lib
INCLUDEDIR ?= $(PREFIX)/include
PYINC ?= $(shell $(PKG_CONFIG) --cflags $(PYPREFIX))
PYLIBS ?= $(shell $(PKG_CONFIG) --libs $(PYPREFIX))
-PYSITEDIR ?= $(shell $(PYTHON) -c 'import site; print(site.getsitepackages()[0])')
+PYTHONLIBDIR ?= $(shell $(PYTHON) -c "from distutils.sysconfig import *; print(get_python_lib(prefix='$(PREFIX)'))")
PYCEXT ?= $(shell $(PYTHON) -c 'import imp;print([s for s,m,t in imp.get_suffixes() if t == imp.C_EXTENSION][0])')
RUBYINC ?= $(shell $(RUBY) -e 'puts "-I" + RbConfig::CONFIG["rubyarchhdrdir"] + " -I" + RbConfig::CONFIG["rubyhdrdir"]')
RUBYLIBS ?= $(shell $(RUBY) -e 'puts "-L" + RbConfig::CONFIG["libdir"] + " -L" + RbConfig::CONFIG["archlibdir"] + " " + RbConfig::CONFIG["LIBRUBYARG_SHARED"]')
@@ -191,10 +191,10 @@ install: all
ln -sf --relative $(DESTDIR)$(SHLIBDIR)/$(LIBSO) $(DESTDIR)$(LIBDIR)/$(TARGET)
install-pywrap: pywrap
- test -d $(DESTDIR)$(PYSITEDIR)/selinux || install -m 755 -d $(DESTDIR)$(PYSITEDIR)/selinux
- install -m 755 $(SWIGSO) $(DESTDIR)$(PYSITEDIR)/_selinux$(PYCEXT)
- install -m 755 $(AUDIT2WHYSO) $(DESTDIR)$(PYSITEDIR)/selinux/audit2why$(PYCEXT)
- install -m 644 $(SWIGPYOUT) $(DESTDIR)$(PYSITEDIR)/selinux/__init__.py
+ test -d $(DESTDIR)$(PYTHONLIBDIR)/selinux || install -m 755 -d $(DESTDIR)$(PYTHONLIBDIR)/selinux
+ install -m 755 $(SWIGSO) $(DESTDIR)$(PYTHONLIBDIR)/_selinux$(PYCEXT)
+ install -m 755 $(AUDIT2WHYSO) $(DESTDIR)$(PYTHONLIBDIR)/selinux/audit2why$(PYCEXT)
+ install -m 644 $(SWIGPYOUT) $(DESTDIR)$(PYTHONLIBDIR)/selinux/__init__.py
install-rubywrap: rubywrap
test -d $(DESTDIR)$(RUBYINSTALL) || install -m 755 -d $(DESTDIR)$(RUBYINSTALL)
diff --git a/libsemanage/src/Makefile b/libsemanage/src/Makefile
index e98d8760acb7..bcee93b36977 100644
--- a/libsemanage/src/Makefile
+++ b/libsemanage/src/Makefile
@@ -13,7 +13,7 @@ LIBDIR ?= $(PREFIX)/lib
INCLUDEDIR ?= $(PREFIX)/include
PYINC ?= $(shell $(PKG_CONFIG) --cflags $(PYPREFIX))
PYLIBS ?= $(shell $(PKG_CONFIG) --libs $(PYPREFIX))
-PYSITEDIR ?= $(shell $(PYTHON) -c 'import site; print(site.getsitepackages()[0])')
+PYTHONLIBDIR ?= $(shell $(PYTHON) -c "from distutils.sysconfig import *; print(get_python_lib(prefix='$(PREFIX)'))")
PYCEXT ?= $(shell $(PYTHON) -c 'import imp;print([s for s,m,t in imp.get_suffixes() if t == imp.C_EXTENSION][0])')
RUBYINC ?= $(shell $(RUBY) -e 'puts "-I" + RbConfig::CONFIG["rubyarchhdrdir"] + " -I" + RbConfig::CONFIG["rubyhdrdir"]')
RUBYLIBS ?= $(shell $(RUBY) -e 'puts "-L" + RbConfig::CONFIG["libdir"] + " -L" + RbConfig::CONFIG["archlibdir"] + " " + RbConfig::CONFIG["LIBRUBYARG_SHARED"]')
@@ -142,9 +142,9 @@ install: all
cd $(DESTDIR)$(LIBDIR) && ln -sf $(LIBSO) $(TARGET)
install-pywrap: pywrap
- test -d $(DESTDIR)$(PYSITEDIR) || install -m 755 -d $(DESTDIR)$(PYSITEDIR)
- install -m 755 $(SWIGSO) $(DESTDIR)$(PYSITEDIR)/_semanage$(PYCEXT)
- install -m 644 semanage.py $(DESTDIR)$(PYSITEDIR)
+ test -d $(DESTDIR)$(PYTHONLIBDIR) || install -m 755 -d $(DESTDIR)$(PYTHONLIBDIR)
+ install -m 755 $(SWIGSO) $(DESTDIR)$(PYTHONLIBDIR)/_semanage$(PYCEXT)
+ install -m 644 semanage.py $(DESTDIR)$(PYTHONLIBDIR)
install-rubywrap: rubywrap
Nicolas Iooss
2018-03-08 21:19:26 UTC
Permalink
Post by Stephen Smalley
Post by Stephen Smalley
Post by Nicolas Iooss
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). 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?

Cheers,
Nicolas
Petr Lautrbach
2018-03-09 12:25:56 UTC
Permalink
Post by Nicolas Iooss
Post by Stephen Smalley
Post by Stephen Smalley
Post by Nicolas Iooss
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).
Post by Stephen Smalley
Post by Stephen Smalley
get_python_lib()
'/usr/lib/python3.6/site-packages'
Post by Nicolas Iooss
Post by Stephen Smalley
Post by Stephen Smalley
get_python_lib(plat_specific=1)
'/usr/lib64/python3.6/site-packages'
Post by Nicolas Iooss
Post by Stephen Smalley
Post by Stephen Smalley
get_python_lib(prefix='/usr/local')
'/usr/local/lib/python3.6/site-packages'
Post by Nicolas Iooss
Post by Stephen Smalley
Post by Stephen Smalley
get_python_lib(prefix='/usr/local', plat_specific=1)
'/usr/local/lib64/python3.6/site-packages'
Post by Nicolas Iooss
And
to be consistent, I suggest naming the variable differently from
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.
Post by Nicolas Iooss
Cheers,
Nicolas
Stephen Smalley
2018-03-09 13:55:11 UTC
Permalink
Post by Petr Lautrbach
Post by Nicolas Iooss
Post by Stephen Smalley
Post by Stephen Smalley
Post by Nicolas Iooss
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).
Post by Stephen Smalley
Post by Stephen Smalley
get_python_lib()
'/usr/lib/python3.6/site-packages'
Post by Nicolas Iooss
Post by Stephen Smalley
Post by Stephen Smalley
get_python_lib(plat_specific=1)
'/usr/lib64/python3.6/site-packages'
Post by Nicolas Iooss
Post by Stephen Smalley
Post by Stephen Smalley
get_python_lib(prefix='/usr/local')
'/usr/local/lib/python3.6/site-packages'
Post by Nicolas Iooss
Post by Stephen Smalley
Post by Stephen Smalley
get_python_lib(prefix='/usr/local', plat_specific=1)
'/usr/local/lib64/python3.6/site-packages'
Post by Nicolas Iooss
And
to be consistent, I suggest naming the variable differently from
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)?
Petr Lautrbach
2018-03-09 14:39:13 UTC
Permalink
Post by Stephen Smalley
Post by Petr Lautrbach
Post by Nicolas Iooss
Post by Stephen Smalley
Post by Stephen Smalley
Post by Nicolas Iooss
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).
Post by Stephen Smalley
Post by Stephen Smalley
get_python_lib()
'/usr/lib/python3.6/site-packages'
Post by Nicolas Iooss
Post by Stephen Smalley
Post by Stephen Smalley
get_python_lib(plat_specific=1)
'/usr/lib64/python3.6/site-packages'
Post by Nicolas Iooss
Post by Stephen Smalley
Post by Stephen Smalley
get_python_lib(prefix='/usr/local')
'/usr/local/lib/python3.6/site-packages'
Post by Nicolas Iooss
Post by Stephen Smalley
Post by Stephen Smalley
get_python_lib(prefix='/usr/local', plat_specific=1)
'/usr/local/lib64/python3.6/site-packages'
Post by Nicolas Iooss
And
to be consistent, I suggest naming the variable differently from
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.
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)?
Yes. Everything from python/ will be moved to /usr/lib to follow the Marcus
change. Currently, It's not in Fedora as I haven't rebased packages yet but it should
happen soon in F28 and Rawhide.
Petr Lautrbach
2018-03-09 21:02:52 UTC
Permalink
Post by Petr Lautrbach
Post by Stephen Smalley
Post by Petr Lautrbach
Post by Nicolas Iooss
Post by Stephen Smalley
Post by Stephen Smalley
Post by Nicolas Iooss
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).
Post by Stephen Smalley
Post by Stephen Smalley
get_python_lib()
'/usr/lib/python3.6/site-packages'
Post by Nicolas Iooss
Post by Stephen Smalley
Post by Stephen Smalley
get_python_lib(plat_specific=1)
'/usr/lib64/python3.6/site-packages'
Post by Nicolas Iooss
Post by Stephen Smalley
Post by Stephen Smalley
get_python_lib(prefix='/usr/local')
'/usr/local/lib/python3.6/site-packages'
Post by Nicolas Iooss
Post by Stephen Smalley
Post by Stephen Smalley
get_python_lib(prefix='/usr/local', plat_specific=1)
'/usr/local/lib64/python3.6/site-packages'
Post by Nicolas Iooss
And
to be consistent, I suggest naming the variable differently from
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.
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)?
Yes. Everything from python/ will be moved to /usr/lib to follow the Marcus
change. Currently, It's not in Fedora as I haven't rebased packages yet but it should
happen soon in F28 and Rawhide.
A test policycoreutils build based on latest changes can be found in my
plautrba/selinux-fedora COPR repo [1]

$ rpm -qpl python2-policycoreutils-2.7-99.fc29.20180309170801.x86_64.rpm python3-policycoreutils-2.7-99.fc29.20180309170801.x86_64.rpm | grep /usr/lib64/ | wc -l
0

$ rpm -qpl python2-policycoreutils-2.7-99.fc29.20180309170801.x86_64.rpm python3-policycoreutils-2.7-99.fc29.20180309170801.x86_64.rpm | grep /usr/lib/ | wc -l
349


[1] https://copr.fedorainfracloud.org/coprs/build/726366/

Loading...