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? > > 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. Fixed this too on the branch - removed the -lselinux from semodule-utils Makefiles. > >> 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. > _______________________________________________ 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.
