Gentoo Archives: gentoo-dev

From: Sven Vermeulen <swift@g.o>
To: gentoo-dev@l.g.o
Subject: [gentoo-dev] Removing 'selinux? ( sec-policy/selinux-*)' from DEPEND
Date: Fri, 29 Aug 2014 15:30:38
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.
5 Hi all
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.
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:
18 DEPEND="selinux? ( sec-policy/selinux-somepolicy )"
19 RDEPEND="selinux? ( sec-policy/selinux-somepolicy )"
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).
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.
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.
36 Given the discussion on dynamic dependencies and so, I am thinking about
37 doing this as follows:
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)
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.
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.
54 Is this a good approach to take?
56 Happy to hear your thoughts on this,
58 Sven Vermeulen