bachradsusi
commented
3 years ago Thanks for you thoughts. Please note that that main discussion point is at selinux@vger.kernel.org mailing list.
Current state causes many difficulties on maintaining SELinux packages tooling.
One repo to rule them all
Theoretically all SELinux tools are in separated source subtrees however and all dist tar balls are released as set of many tar balls however:
* many times single git commit is done across many subdirectories which makes very difficult extracting patches from git after latest release
I use git format-patch... -- <directory>:
$ git show 4a142ac46a11 -- libsepol | grep -E 'diff.*(libselinux|libsepol)'
diff --git a/libsepol/src/Makefile b/libsepol/src/Makefile
$ git show 4a142ac46a11 -- libselinux | grep -E 'diff.*(libselinux|libsepol)'
diff --git a/libselinux/src/load_policy.c b/libselinux/src/load_policy.c
$ git show 4a142ac46a11 | grep -E 'diff.*(libselinux|libsepol)'
diff --git a/libselinux/src/load_policy.c b/libselinux/src/load_policy.c
diff --git a/libsepol/src/Makefile b/libsepol/src/Makefile* because everything is in one repo changes in each subdirectories must wait on that one (master) release and _sometimes that release even does not introduce any changes in some directors_
Could you please share the concrete change which was not propagated to new release?
* despite semi modularisation test suite seems is maintained in assumption that it will be executed in main selinux directory. Example is libsepol test suite:+ /usr/bin/make -O -j1 V=1 VERBOSE=1 test /usr/bin/make -C tests test make[1]: Entering directory '/home/tkloczko/rpmbuild/BUILD/libsepol-3.1/tests' gcc -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fstack-protector-strong -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -fdata-sections -ffunction-sections -Os -I../include/ -I../../checkpolicy/ -c -o debug.o debug.c gcc -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fstack-protector-strong -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -fdata-sections -ffunction-sections -Os -I../include/ -I../../checkpolicy/ -c -o helpers.o helpers.c helpers.c:25:10: fatal error: parse_util.h: No such file or directory 25 | #include "parse_util.h" | ^~~~~~~~~~~~~~ compilation terminated. make[1]: *** [<builtin>: helpers.o] Error 1That parse_util.h is not part of public checkpolicy API and for example in Fedora there is no checkpolicy-devel package
* there are circular dependencies like checkpolicy during build requires libsepol and libsepol requires header files provide by checkpolicy (like in libsepol test suite uses checkpolicy headers)
In fact libsepol doesn't requires checkpolicy to build, the test suite is not part of the build process
all:
$(MAKE) -C src
$(MAKE) -C utils* there is no proper separation between public and private API. This why currently is not possible to use only shared libraries
I see this as the public API is declared in libsepol/include, libselinux/include and libsemanage/include, everythin else is internal API.
How to solve above issues all together?
* start maintaining SELinux tooling in separated git modules. Proper separation can be done continuously with extracting one by one each necessary part and remove it from SELinuxProject/selinux * introduce proper build framework using for example meson with checking build dependencies using * define properly libraries public interface and use only that API in other modules * start release each module (currently directories) with own versioning. This would allow smooth fixing critical issues * divide current test suite and spread across each component with using only other components public API/ABI and test internal API only inside each componentIf you are not familiar with meson I can offer to help on that part. Using meson would allow solve many other issues like transparent LTO or PGO optimisation, easy integration of test units, coverage, generate dist tar balls and many other.
You propose quite a big change which needs to be discussed at selinux@vger.kernel.org mailing list. Also feel free to send patches there, see https://github.com/SELinuxProject/selinux/blob/master/CONTRIBUTING.md for instructions.
kloczek
williamcroberts
fishilico
Current state causes many difficulties on maintaining SELinux packages tooling.
One repo to rule them all
Theoretically all SELinux tools are in separated source subtrees however and all dist tar balls are released as set of many tar balls however:
~~~~~ compilation terminated. make[1]: *** [How to solve above issues all together?
If you are not familiar with meson I can offer to help on that part. Using meson would allow solve many other issues like transparent LTO or PGO optimisation, easy integration of test units, coverage, generate dist tar balls and many other.