Re: [PATCH] package_rpm: Add optional improved directory handling

[Mark Hatle <mark.hatle@windriver.com>]

On 8/29/14, 5:32 PM, Richard Purdie wrote:
> 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).

So the switch then is empty value vs not defined?

If so that is what I was missing.

--Mark

> Cheers,
>
> Richard
>
>
>