[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gentoo-dev
Subject:    [gentoo-dev] Removing 'selinux? ( sec-policy/selinux-*)' from DEPEND
From:       Sven Vermeulen <swift () gentoo ! org>
Date:       2014-08-29 15:30:29
Message-ID: 20140829153028.GA5082 () gentoo ! org
[Download RAW message or body]

tldr; I want to remove USE="selinux" deps from DEPEND in
non-libselinux-linking packages in a sane manner and use a bug tracker with
6 months timeframe.

Hi all

In the past, to enable proper SELinux support in our tree, we had to have
the appropriate SELinux policy modules installed and loaded before the
package/application for which the policy was designed is merged to the
system. The reason is that otherwise the files installed on the system will
have the wrong labels assigned, making the applications unable to function
properly.

We implemented this by having the USE="selinux" triggered dependency in both
DEPEND (needed before merge) and RDEPEND (policy needs to be available
during runtime), like so:

DEPEND="selinux? ( sec-policy/selinux-somepolicy )"
RDEPEND="selinux? ( sec-policy/selinux-somepolicy )"

Recently, we updated the SELinux eclass so that after installation of a
policy package, the reverse dependencies of that package are looked up and
those reverse dependencies are relabeled (i.e. proper SELinux labels are
assigned to the files of that package).

With this change, we implement the same end result (correctly labeled files
after installation) while removing the need for the DEPEND dependency. After
all, this was not a build-time dependency but a "merge-time" one, which we
abused a bit to make things work.

With this change in place, we can now update the tree (at least, for those
packages that do not have other SELinux related dependency requirements -
those that link with libselinux still need it in DEPEND of course) to remove
the USE="selinux" conditional dependency from DEPEND.

Given the discussion on dynamic dependencies and so, I am thinking about
doing this as follows:

1. Create a tracker with separate bugs for every package where this change
   can be made
2. Give developers time to apply this (simple) change together with whatever
   other changes they were planning.
3. After 6 months or so, do the change myself (with revbump)

I don't think it is useful for end users that I do the change immediately as
this creates package bumps (and rebuilds) with no real benefit, and not
bumping is also not a good idea given the discussion on dynamic dependencies
in the past.

By providing a 6-months period, developers can put in this change when they
are bumping the package themselves (for functional and other reasons) and
the bugs (with tracker) allow developers to not forget this.

Is this a good approach to take?

Happy to hear your thoughts on this,

	Sven Vermeulen

[prev in list] [next in list] [prev in thread] [next in thread]