[refpolicy] [PATCH] Add Debian location for rtkit-daemon daemon

Dominick Grift dominick.grift at gmail.com
Sun Sep 16 15:45:14 CDT 2012



On Sun, 2012-09-16 at 21:31 +0200, Elia Pinto wrote:
> If you like to hear a luser, more or less, opinion mostly the problem
> that today the refpolicy have is because exists other project that
> forked it, right or wrong it is not important. And apparently none
> care. And none care where someone have to send patches, improvment ,
> new policy. Is it a good thing ? Perhaps i have missed something ?
> Dunno

I do not believe that it is true that no one cares but distributions do
sometimes have priorities that do not always align with upstreams'
priorities. It is a tough world out there for businesses that need to
send pay checks to employees.

I think that people understand that working with upstream is probably
the sustainable solution in the long term. It is just easier said than
done when one is facing deadlines et cetera.

Also it is a matter of resources for those community projects that do
not have a commercial incentive i suspect. Many distributions do not
enable selinux by default and do not have many policy authors and
contributors.

Currently we have, in my view, a good impulse. We have SwifT on behalf
of Gentoo contributing and we have bigon contributing on behalf of
debian.

I currently do some porting for and contributing on behalf of Fedora and
hopefully mgrepl will also help out, and help solve remaining issues.

Reference policy is called this way for a reason and so i guess it is
reasonable to expect some changes between policies that distributions
ship and refpolicy. However there does not have to a big difference
since essentially the policy that a distribution ships is also a
reference policy and both are pretty much general purpose policies.

Anyways, this is off topic in my opinion. This topic is about not using
if(n)?def(`') in file context files and i think that it should not be a
big problem to have some possibly redundant file context specs for the
sake of guaranteeing backwards compatibility.





More information about the refpolicy mailing list