1 |
tldr; I want to remove USE="selinux" deps from DEPEND in |
2 |
non-libselinux-linking packages in a sane manner and use a bug tracker with |
3 |
6 months timeframe. |
4 |
|
5 |
Hi all |
6 |
|
7 |
In the past, to enable proper SELinux support in our tree, we had to have |
8 |
the appropriate SELinux policy modules installed and loaded before the |
9 |
package/application for which the policy was designed is merged to the |
10 |
system. The reason is that otherwise the files installed on the system will |
11 |
have the wrong labels assigned, making the applications unable to function |
12 |
properly. |
13 |
|
14 |
We implemented this by having the USE="selinux" triggered dependency in both |
15 |
DEPEND (needed before merge) and RDEPEND (policy needs to be available |
16 |
during runtime), like so: |
17 |
|
18 |
DEPEND="selinux? ( sec-policy/selinux-somepolicy )" |
19 |
RDEPEND="selinux? ( sec-policy/selinux-somepolicy )" |
20 |
|
21 |
Recently, we updated the SELinux eclass so that after installation of a |
22 |
policy package, the reverse dependencies of that package are looked up and |
23 |
those reverse dependencies are relabeled (i.e. proper SELinux labels are |
24 |
assigned to the files of that package). |
25 |
|
26 |
With this change, we implement the same end result (correctly labeled files |
27 |
after installation) while removing the need for the DEPEND dependency. After |
28 |
all, this was not a build-time dependency but a "merge-time" one, which we |
29 |
abused a bit to make things work. |
30 |
|
31 |
With this change in place, we can now update the tree (at least, for those |
32 |
packages that do not have other SELinux related dependency requirements - |
33 |
those that link with libselinux still need it in DEPEND of course) to remove |
34 |
the USE="selinux" conditional dependency from DEPEND. |
35 |
|
36 |
Given the discussion on dynamic dependencies and so, I am thinking about |
37 |
doing this as follows: |
38 |
|
39 |
1. Create a tracker with separate bugs for every package where this change |
40 |
can be made |
41 |
2. Give developers time to apply this (simple) change together with whatever |
42 |
other changes they were planning. |
43 |
3. After 6 months or so, do the change myself (with revbump) |
44 |
|
45 |
I don't think it is useful for end users that I do the change immediately as |
46 |
this creates package bumps (and rebuilds) with no real benefit, and not |
47 |
bumping is also not a good idea given the discussion on dynamic dependencies |
48 |
in the past. |
49 |
|
50 |
By providing a 6-months period, developers can put in this change when they |
51 |
are bumping the package themselves (for functional and other reasons) and |
52 |
the bugs (with tracker) allow developers to not forget this. |
53 |
|
54 |
Is this a good approach to take? |
55 |
|
56 |
Happy to hear your thoughts on this, |
57 |
|
58 |
Sven Vermeulen |