| 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 |
Archives