On Mon, Oct 24, 2016 at 09:13:42AM -0400, Stephen Smalley wrote: > On 10/22/2016 09:44 AM, Chris PeBenito wrote: > > On 10/21/16 13:47, Stephen Smalley wrote: > >> policycoreutils started life as a small set of utilities that were > >> necessary or at least widely used in production on a SELinux system. > >> Over time though it has grown to include many optional components, and > >> even within a given subdirectory (e.g. sepolicy) there seem to be a > >> number of components that should be optional (e.g. the dbus service). > >> I'd like to propose that we move a number of components out of > >> policycoreutils into their own top-level subdirectory (possibly grouping > >> some of the related ones together). I'm also in favour of splitting. As Sven said, we conditionally compile things with USE-flags in gentoo instead of separate packages but that can easily change. Live would probably be easier since then there would be no patching to make it conditional. We dont even package sandbox and quite a few other things at all. We do also have a policycoreutils-extra (has rlpkg and a few other things) which I have been meaning to upstream but havent gotten around to it yet. If things are getting split those could be added to whatever policyextrautils package we end up with. > > I'm not sure where the main part of sepolicy should go, but it would be > > nice to split it out since it depends on setools which has heavier > > dependencies than a core system package should typically have IMO > > (NetworkX, which pulls in scipy, numpy, matplotlib, etc.) > > I would be in favor of that too, but hesitated to do so because it would > require moving audit2allow and semanage out of policycoreutils as well. > Fedora does package those as part of policycoreutils-python (along with > sepolgen). Arguably audit2allow isn't necessary for production (but > many users of SELinux in Linux distributions rely on it), but semanage > is more fundamental these days. > > However, if people are open to moving sepolicy, audit2allow, and > semanage, possibly combining them with sepolgen in a new > subdirectory/package, then we could explore that. My eventual goal for seobject.py was to just kill it, there isnt really anything that setools4 doesnt have. For the last release mostly due to lack of time I changed several parts to just be sort of thin wrappers around setools. sepolicy also seemed like two separate things. one part was a kind of library thing which i updated to use setools4 too, that would be better off dying or being a separate small lib. then there is the whole gui part of sepolicy which can probably be split out. I dont think i've ever personally used the gui. semanage only requires the lib parts. I havent looked too much into the core of setools4 other than what I needed to update sepolicy so I'm not sure how important networkX and stuff are. semanage might only require the base stuff if we're able to split that out? -- Jason _______________________________________________ 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.
