1 |
On Sat, Feb 12, 2011 at 01:43:40PM -0600, Chris Richards wrote: |
2 |
> TBH, I really see nothing wrong with the naming convention we are using |
3 |
> now, which (AFAIK) pretty much follows the upstream module naming |
4 |
> convention (which I think is what you are proposing). |
5 |
|
6 |
Indeed; however I couldn't find a post or something that reflects that we |
7 |
are indeed trying to following the upstream module naming. For instance, the |
8 |
packages selinux-acpi (mod=apm), selinux-courier-imap (mod=courier), |
9 |
selinux-cyrus-sasl (mod=sasl), selinux-desktop (various mods), selinux-ftpd |
10 |
(mod=ftp), selinux-gnupg (mod=gpg) and more all don't follow this logic, |
11 |
even though I see no reason why they don't (except for the selinux-desktop |
12 |
one). |
13 |
|
14 |
It looked/looks like those packages rather follow the Gentoo package names |
15 |
instead of the SELinux module. |
16 |
|
17 |
> I also am not following the argument about 'make duplicate packages'? |
18 |
> If a policy module ebuild can work for multiple different packages, that |
19 |
> is fine. We simply have an optional selinux dependency in each of the |
20 |
> application ebuilds on that same selinux module. If the module is |
21 |
> already installed then the dependency is already satisfied. If not, |
22 |
> then we pull it in. Or am I missing something? |
23 |
|
24 |
Actually, the argument is only valid if we would require our policy packages |
25 |
to be named after the package. If we follow the reference policy module |
26 |
names, the argument is void. |
27 |
|
28 |
> As blueness has pointed out, renaming a bunch of packages is a PITA. I |
29 |
> really don't see that we get anything from doing so at this point, |
30 |
> except a bunch of pain. |
31 |
|
32 |
Actually, I'm rather hoping that if everyone agrees on the guideline that |
33 |
SELinux policy packages are called "selinux-<modname>" with <modname> being |
34 |
the policy name used by the reference policy, that we can use that as well |
35 |
in the Gentoo Hardened SELinux Policy document [1]. |
36 |
|
37 |
By doing so, future developers immediately know how Gentoo Hardened works |
38 |
(it is documented, so they don't need to start pondering how to call the |
39 |
policy package for module "foo"). |
40 |
|
41 |
Wkr, |
42 |
Sven Vermeulen |
43 |
|
44 |
[1] goo.gl/2U0Zr |