Notably, Python 2 code is not be supported in this project anymore and
new Python code should be written only for Python 3, which is no longer
restricted to Python 3.7 (see 780fb563c74171aafc2fb802cfdebd56a68d0705,
5dfd3c497540bb172ff0d04cc8eb5ecbeb59b938)
https://github.com/SELinuxProject/selinux/releases/tag/20191204
Fixes a bug where the build system tried to call `git` to embed the
release tag revision into the binary, which isn't allowed. Easily fixed
with `substituteInPlace`.
Also updates the expression to be a little closer to "standard"
expressions (e.g. consistent indentation, importing `stdenv` instead of
`lib` and `mkDerivation`, etc.)
Signed-off-by: Austin Seipp <aseipp@pobox.com>
As requested in #99553. Closes#99553.
Libraries that install python modules as part of the build are
problematic, because they either
- only support a single python version, because the input for
pythonPackages gets fixed in all-packages.nix, or
- need to be rebuild the underlying C code for *every* python version
resulting in libfoo-python37, libfoo-python38, and so on
We would prefer to use the second approach because it works correctly
for all versions of python. However, it creates duplicate copies of
libseccomp.so and that can be expensive. Instead we 'deduplicate' the
copies of libseccomp.so by
- attaching a new $pythonsrc output to the libseccomp deriv, and
- exposing a new 'seccomp' package in python-packages.nix using
libseccomp as input, and
- having a custom python.nix derivation that builds the cython
extension using libseccomp to get the python source and the
package version
This means we build 1 copy of the seccomp python package, one for each
version of python, but all of those packages refer to a single instance
of the libseccomp C library, giving us the best of both worlds.
NOTE: because this requires changing the postInstall of libseccomp, it
requires a mass rebuild.
Signed-off-by: Austin Seipp <aseipp@pobox.com>
