[OE-core] [PATCH] package_rpm: Add optional improved directory handling

[Richard Purdie]

On Fri, 2014-08-29 at 17:13 -0500, Mark Hatle wrote:
> On 8/29/14, 5:02 PM, Richard Purdie wrote:
> > On Fri, 2014-08-29 at 13:36 -0500, Mark Hatle wrote:
> > Going back in time, I remember us specifically talking about directory
> > ownership and how we likely should try and reach a point where the
> > common system directories do become owned by specific packages. With
> > this kind of DIRFILES support we could move in the direction. The perms
> > tables obviously help to a point ensuring consistent permissions but
> > they don't help the ownership problem. Or is this less of an issue since
> > we last discussed it (which admittedly was a while ago)?
> 
> No there is currently nothing that says I exclusively own a directory (or link). 
>   The fs-perms.txt could be extended to do this (in a transparent way).
> 
> My concern with the DIRFILES as it appears to be implemented can be shown in the 
> existing example:
> 
> I create a new recipe that writes:
> 
> /etc/foo.conf
> /usr/bin/foo
> 
> (that's it)
> 
> 
> In the SMACK case, the /etc and /usr/bin directories shouldn't be included.. so 
> how do we define DIRFILES?  If it's blank, they'll be included.. but we don't 
> have any directories to set it to... so do we need to do:
>     DIRFILES = "something_random_so_it_works"
> 
> That seems very counter intuitive to me.
> 
> This is why I'm suggesting an inverse relationship..  We include everything 
> other then explicitly listed directories.  That way the user can globally define 
> /etc, /usr/bin, ... and individual recipes can augment this with their own 
> custom values if appropriate.
> 
> and in the default (oe-core) case no change means the directories will continue 
> to be included -- no flag days required.

I'm more thinking that when we reach this stage, the core would end up
setting:

DIRFILES = ""

as the default (think a core class or conf file), then recipes can
override as needed. You don't need something_random_so_it_works, I had
the empty value specifically in mind to trigger this from the core (as
opposed to None where the variable isn't set at all).

Cheers,

Richard