Hi, policycoreutils started life as a minimalist set of utilities required for SELinux operation. It has grown far beyond that, and now includes a number of non-essential components. Some of those components have also grown dependencies on external libraries from setools (in particular, sepolicy, which is now a dependency for semanage, sandbox, and gui?). So I was wondering whether it is worthwhile to split up policycoreutils into multiple source packages, or otherwise support a minimalist build of it. Fedora already generates multiple separate binary packages from it: 1) policycoreutils (secon, semodule_*, fixfiles, genhomedircon, load_policy, restorecon, run_init, semodule, sestatus, setfiles, setsebool) Not sure what relies upon secon that leads to it being included in the base package - maybe init scripts? semodule_deps, semodule_expand, and semodule_link are all purely developer tools that shouldn't be needed in common practice. semodule_package is necessary only if building policy modules, so I'd tend to put that in a -devel package. Not sure whether run_init is truly required in Fedora outside of -mls policy? sestatus isn't required for operation but is convenient to have. The rest make sense to me as part of the base package. 2) policycoreutils-devel (sepolicy and sepolgen* from the separate sepolgen source package, which gets combined into the policycoreutils source package in Fedora) Not sure how much sense this one makes in its current form separate from policycoreutils-python below. 3) policycoreutils-python (audit2allow, audit2why, seamanage, chcat, sandbox?, /usr/lib*/python*/site-packages/*) Confused by why sandbox appears here but its dependencies are below in policycoreutils-sandbox. audit2allow/audit2why are effectively policy development tools. chcat seems more like a base utility although I'm not sure how many people use it rather than just using chcon -l or semanage these days. semanage is required for management if using managed/modular policy, so it is more fundamental than audit2allow/audit2why, chcat, or sandbox. 4) policycoreutils-gui (selinux-polgengui, system-config-selinux) Seems reasonable. 5) policycoreutils-newrole (newrole) I'd tend to put this into the base or at least with run_init. IIRC, it was only separated to avoid having an unnecessary setuid/file-caps binary in the non-MLS case. If the common thread is MLS, then I'd tend to put newrole, run_init, and chcat together. 6) policycoreutils-restorecond (restorecond) Makes sense as an optional component. 7) policycoreutils-sandbox (seunshare, /usr/share/sandbox) Ditto, except that I'd expect sandbox from policycoreutils-python in this one too. So, I guess the question is whether it provides any value to split up the source package itself (as opposed to just the generated packages), and if so, what the best decomposition is. -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@xxxxxxxxxxxxx with the words "unsubscribe selinux" without quotes as the message.
