Re: Ownership issue in package contents

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

On 4/6/15 9:57 AM, Otavio Salvador wrote:
> On Mon, Apr 6, 2015 at 11:53 AM, Mark Hatle <mark.hatle@windriver.com> wrote:
>> On 4/6/15 7:59 AM, Mario Domenech Goulart wrote:
>>> Hi Mark and all,
>>
>> ...
>>
>>> Thanks for all the hints and for your patience.
>>>
>>> It looks like I was caught by a messed up TMPDIR.  After I removed
>>> TMPDIR and baked the foo recipe, everything works.  I could make it work
>>> by adding
>>>
>>>   FILESYSTEM_PERMS_TABLES = "files/fs-perms.txt ${THISDIR}/${PN}/fs-perms-foo.txt"
>>>
>>> to the foo.bb recipe.  In this case files/fs-perms.txt is the global
>>> default one and ${THISDIR}/${PN}/fs-perms-foo.txt is the foo-specific
>>> one that has one line only, which sets the permissions for
>>> ${libexecdir}.
>>>
>>> I had to explicitly prepend files/fs-perms.txt because packages.bbclass
>>> would not pick files/fs-perms.txt if FILESYSTEM_PERMS_TABLES is set.
>>
>> I've often thought that we probably should make FILESYSTEM_PERMS_TABLES into a
>> globally defined configuration (bitbake.conf) and remove the default from the
>> package.bbclass.  The design here was old, and based on even older code that was
>> specific to device node generation.
>>
>> A patch to do this would likely be accepted.  (I'd make it so that an empty
>> value would simply run through just the default internal values.)
> 
> I would think that OE-Core/files/fs-perms.txt should always be run as
> first item and recipe or layer ones could be appended to it. So we can
> avoid a lot of duplication and provide a more predictable behavior.
> 

It wasn't done this way originally, because the assumption was that a
distribution layer may want to provide it's own file and avoid using any
defaults from OE.

--Mark