On Sat, Feb 12, 2011 at 01:43:40PM -0600, Chris Richards wrote:
> TBH, I really see nothing wrong with the naming convention we are using 
> now, which (AFAIK) pretty much follows the upstream module naming 
> convention (which I think is what you are proposing).  

Indeed; however I couldn't find a post or something that reflects that we
are indeed trying to following the upstream module naming. For instance, the
packages selinux-acpi (mod=apm), selinux-courier-imap (mod=courier),
selinux-cyrus-sasl (mod=sasl), selinux-desktop (various mods), selinux-ftpd
(mod=ftp), selinux-gnupg (mod=gpg) and more all don't follow this logic,
even though I see no reason why they don't (except for the selinux-desktop
one).

It looked/looks like those packages rather follow the Gentoo package names
instead of the SELinux module.

> I also am not following the argument about 'make duplicate packages'?  
> If a policy module ebuild can work for multiple different packages, that 
> is fine.  We simply have an optional selinux dependency in each of the 
> application ebuilds on that same selinux module.  If the module is 
> already installed then the dependency is already satisfied.  If not, 
> then we pull it in.  Or am I missing something?

Actually, the argument is only valid if we would require our policy packages
to be named after the package. If we follow the reference policy module
names, the argument is void.

> As blueness has pointed out, renaming a bunch of packages is a PITA.  I 
> really don't see that we get anything from doing so at this point, 
> except a bunch of pain.

Actually, I'm rather hoping that if everyone agrees on the guideline that
SELinux policy packages are called "selinux-<modname>" with <modname> being
the policy name used by the reference policy, that we can use that as well
in the Gentoo Hardened SELinux Policy document [1]. 

By doing so, future developers immediately know how Gentoo Hardened works
(it is documented, so they don't need to start pondering how to call the
policy package for module "foo").

Wkr,
        Sven Vermeulen

[1] goo.gl/2U0Zr

Reply via email to