From: cpebenito@tresys.com (Christopher J. PeBenito)
Date: Fri, 21 Jan 2011 07:37:58 -0500
Subject: [refpolicy] RFC: patch to update git reference policy
In-Reply-To: <1295544776.4702.16.camel@tesla.lan>
References: <1295397630.3377.10.camel@tesla.lan> <4D383627.60804@tresys.com>
	<1295544776.4702.16.camel@tesla.lan>
Message-ID: <4D397E26.4090904@tresys.com>
To: refpolicy@oss.tresys.com
List-Id: refpolicy.oss.tresys.com

On 01/20/11 12:32, Guido Trentalancia wrote:
> Hello Christopher,
> 
> thanks for getting back !
> 
> On Thu, 20/01/2011 at 08.18 -0500, Christopher J. PeBenito wrote:
>> On 01/18/11 19:40, Guido Trentalancia wrote:
>>> Hello,
>>>
>>> I have created a set of two patches to update the git reference policy
>>> to run on a generic modern Linux system.
>>
>> There are too many changes in this patch and the other.  Can you
>> resubmit, breaking each logically separate change into a different patch?
> 
> Yes, I think that can be done, although it might take some time. But
> what do you mean exactly for "logically separate" ?

An example is adding a new interface and adding calls for it in other
modules.  It looks like you have a bunch of dbus messaging additions;
you can make that one patch.

> In truth both patches are not logically separated, because of their
> common aim to update refpolicy to work on a modern installation more or
> less by adding some missing permissions.

That means its a pile of logical changes.

> I could create a separate patch for each module x (x.fc, x.if, x.te)...
> 
> I am not sure this is what you meant. For example, I have (almost) never
> created a bidirectional dbus:send_msg permission in a module, but rather
> split them in two unidirectional dbus:send_msg permissions in the two
> modules that are relevant in that case. So, in this example, splitting
> the patch according to modules would break that logic because each
> module just implements a unidirectional dbus:send_msg (relative to its
> own context only) and the single patch won't completely solve the issue.

Definitely not what I meant.

-- 
Chris PeBenito
Tresys Technology, LLC
www.tresys.com | oss.tresys.com