On 11/14/2016 03:41 PM, Jason Zaman wrote: > These look pretty good to me. I have written most of the ebuilds for > gentoo for these new packages but have not committed to the tree yet. > > There are a couple issues: > 1) What is the license for each of the tarballs? there is no license or > COPYING file in the dirs. Fixed; I copied the policycoreutils/COPYING file into each of the new ones since they were all moved from policycoreutils. > > 2) even tho i fixed up a lot of it so shouldnt be, I am *super* confused > about sepolicy vs sepolgen. there are like 4 separate dirs with those > names and the sepolicy Makefile makes a symlink for sepolgen. And then > there is the gui and the non-gui part of them. python/sepolicy/* should > hopefully die soon as things fully move over to setools4. should gui/ be > called system-config-selinux? also is it a redhatism or does it also > apply to other distros? I also find this confusing; hopefully Dan (cc'd) can help clarify matters since he wrote most of this code. I do know that the old sepolgen package (now python/sepolgen) was just a python module used as the backend for audit2allow and intended to become a more general policy analysis and generation backend, but never evolved that way, whereas gui/sepolgen was the old name for Dan's policy generation script/tool that is now just an alias for sepolicy generate. gui could be called system-config-selinux, but then it can also be invoked as sepolicy gui. It certainly started life as a Red Hat tool, but I'm not sure if anyone else is using it. Refactoring all of it, including semanage/seobject.py, may make sense. > 3) The deps of each of the bits is somewhat complicated to figure out. > semodule-utils looks like it only needs libsepol and libselinux and the > others look like they need most of the others? The makefile just builds > them in order but i'd like to specify more accurate deps in the gentoo > packages (especially external deps for each package) so they get > (re)built as required as things update. I was also trying to make it easy to omit the optional components (OPT_SUBDIRS in the top-level Makefile), i.e. the ones that are not required for operation. I would omit at least dbus, gui, mcstrans, restorecond, and sandbox by default from a base install. python is likely needed for general purpose distros but could be omitted from embedded systems. Actually, I don't see why semodule-utils components are linking with libselinux; they do not include selinux.h or make any calls to libselinux AFAICS, so I think that only truly depends on libsepol. > Also which of these are required to build refpolicy? the docs on that > may need updating later too. I would only expect libsepol, checkpolicy, and semodule-utils to be needed to build refpolicy, while libsemanage and policycoreutils would also be needed to install/load refpolicy. > 4) mcstrans fails to build on my laptop, i'll send patches later. I > might have stricter warnings on or something. Ok, I already had to fix a number of such warnings for it when I re-enabled building it by default on that branch (it was disabled before), so not surprised - just send the patches our way. > 5) in python/sepolicy/Makefile: > override CFLAGS += -I$(PREFIX)/include -DPACKAGE="policycoreutils" > should that be something instead of policycoreutils now? Probably can be removed entirely. > 6) we have a policycoreutils-extra thats been floating around as part of > policycoreutils in gentoo. Mainly has rlpkg and selocal. After this > split is as good a time as any to cleanup and upstream them. Ok, in that case we might want to think about what else if anything might go there. > 7) I just noticed when looking through different Makefiles that some > variables default to different things. I'll send patches for this too > later once its merged in. Its nothing huge just better to be the same. > >> Note that the release script will add the selinux- prefix for dbus, gui, >> python, and sandbox when generating the source tarballs so that they >> have unique names suitable for source packages. > > This makes sense but I wonder if the name prefix is going to be annoying > when we end up needing to backport a patch on a release since the paths > would be different. But then again we've always had to edit them since > they are one level down so I dont think I mind this minor extra bit too. Open to suggestions; I could add the prefix in the source tree itself; it just seemed ugly/unnecessary. Or we could split up the repository into multiple ones / submodules, but I'm not keen on that. _______________________________________________ Selinux mailing list Selinux@xxxxxxxxxxxxx To unsubscribe, send email to Selinux-leave@xxxxxxxxxxxxx. To get help, send an email containing "help" to Selinux-request@xxxxxxxxxxxxx.