Hi guys, In the "Gentoo Hardened SELinux Development Policy" [1] we have a section requiring development to use the 'gentoo_' prefix. The reason for that was to ensure no collisions occur when a patch is added upstream.
[1] http://www.gentoo.org/proj/en/hardened/selinux-policy.xml However, with the release of 20110726 and other changes, I'm pondering about removing this section from the guideline, and here is why... First of all, "safe migration" is not possible. We had around 40-something patches applied to 20101213 and less than one third could still be applied to 20110726. Not because the patch was included, but because the structure of the code had changed. All other patches needed to be made manual anyhow. Using gentoo_ prefix or not wouldn't make a difference here. Second, if a collision occurs, we would either get a failed patch (which we can then safely drop from our patch bundle) or a duplicate definition (which we will notice during builds, after which we can update our patches). Using gentoo_ prefix or not wouldn't make a difference here. Third, we are pushing many of our changes upstream. However, as long as we use different naming conventions, then the patches cannot easily be pushed. Currently, I'm manually typing over most patches that include gentoo_ prefixes into a reference policy checkout for submitting upstream, which is *very* time consuming. Using gentoo_ prefix is a time hogger. Using upstream naming convention would be much leaner. Fourth, supporting tools that help SELinux developers for a proper coding style as well as other documents and guidelines are often based on the naming convention. By using a gentoo_ prefix, these tools give warnings (and the documents are less valid). If we need anything at all, a suffix would be much more flexible. Using gentoo_ prefix here is causing development efforts to become more difficult. I'd rather use the gentoo_ prefix for those things that we *know* are not to be merged upstream anytime soon and which are /Gentoo/ specific (like some of our booleans). Any objections here? Wkr, Sven Vermeulen
