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 -- _______________________________________________ Openembedded-core mailing list [email protected] http://lists.openembedded.org/mailman/listinfo/openembedded-core
