On 11/15/2016 09:47 AM, Stephen Smalley wrote: > 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? sepolicy is a big python library used to generate things like the man pages and all of the policy analyses tools. The goal was to change seinfo and sesearch output into something more easily consumed by non SELinux experts. sepolgen as Stephen said is just a link to sepolicy generate code which is used heavily for generating policy templates. sepolicy libraries are used by the sepolicy command suite. > 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.
