Re: How to overlay files/fs-perms.txt?

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

On 10/11/11 2:03 PM, Mark Hatle wrote:
> On 10/11/11 5:42 AM, Koen Kooi wrote:
>> Hi,
>>
>> In angstrom we have base-files overlayed to clean out /var and files/fs-perms.txt is getting in the way of that:
>>
>> koen@dominion:/OE/tentacle/sources/openembedded-core/meta$ grep localstate files/fs-perms.txt 
>> ${localstatedir}/cache	link	volatile/cache
>> ${localstatedir}/run	link	volatile/run
>> ${localstatedir}/log	link	volatile/log
>> ${localstatedir}/lock	link	volatile/lock
>> ${localstatedir}/tmp	link	volatile/tmp
>>
>> In angstrom those aren't symlinks anymore, but tmpfs bind mounts managed by systemd.

Sorry to reply to my reply... but I just realized I left one thing out.

Follow the items below, and add entries for each of the links and list then as
directory types instead.  The code will load the files in order.. any duplicates
the last setting is what is used.

--Mark

>> So, how doI overlay that file in this oe-core layer universe?
> 
> This came up recently in regards to the Yocto documentation.  Below is the
> snipped of conversation we had working on docs:
> 
>>> I was discussing the fs-perms.txt file and the FILESYSTEM_PERMS_TABLES variable
>>> with Paul.  We got the point of user-scenarios.  Paul said that he would
>>> recommend not setting the variable at all and just letting it default to our
>>> fs-perms.txt file.  At which point I asked why have the variable then?  Paul
>>> pointed me off to you at that point.
>>>
>> Reasons to set it.
>>
>> You have custom files/directories in your layer and need to specify them via a
>> custom fs-perms.txt file.  (More then one can be specified...)  The file (or
>> files) is "distribution specific".  I.e. the distribution the developer is
>> creating needs a consistent fs-perms.txt across the entire work product.  For
>> directories shared between packages, that use non-standard permissions, owners
>> and/or groups, this is the way to synchronize the information.  (Note, it's
>> better to sync within the packages themselves, but that is not always possible
>> to do.. primarily for the core package set.)
>>
>>> So what I am trying to understand here is how a customer would go about using
>>> their own fs-perms.txt file.  Since we have the FILESYSTEM_PERMS_TABLES variable
>>> I presume someone can set it to point to an fs-perms.txt file of their own.  Can
>>> tell me how they do that with some answers to the following?
>>>
>> FILESYSTEM_PERMS_TABLES is by default "files/fs-perms.txt".  One or more file
>> can be added to this list.  Each file listed will be scanned for via the BBPATH.
>>  So you might end up with a "files/intel-perms.txt".  This could be an Intel
>> specific version of the file.  Or set it to "files/fs-perms.txt
>> files/intel-perms.txt".  In this case it will use BOTH the default and the newly
>> mentioned intel-perms.txt.
>>
>>> ·         They create their own file following the syntax of the fs-perms.txt
>>> file we supply and put it anywhere they want?
>> The path specified must be within the BBPATH.
>>
>>> ·         They edit the existing fs-perms.txt file we supply?  (probably not a
>>> good idea but thought I would ask)
>> It is best for them to supply their own file and include it in addition to the
>> default file -- or completely replace the stock file.  (editing the stock
>> version makes long term maintenance more difficult if we need to make changes to
>> it in the future.)
>>
>>> ·         Where do they set the FILESYSTEM_PERMS_TABLES variable?  We set it in
>>> a place that they should not edit.
>> local.conf or any other place where bitbake variables can be set.
>>
>>> ·         Is the FILESYSTEM_PERMS-TABLES variable something that should just
>>> remain hidden?
>> I doubt it will be useful for general purpose stuff.. It's really for
>> distribution creators, more then distribution "users".  Most of our (Yocto and
>> OE-Core) user base are "users".  They use what we give them as a basis for their
>> work, and then add to it.  A distribution creator is someone who is going to
>> potentially chance the rules of the filesystem and where things belong to suit
>> their (or their customers) needs.
> 
> Hopefully this helps.
> 
> --Mark
> 
>> regards,
>>
>> Koen
>> _______________________________________________
>> Openembedded-core mailing list
>> Openembedded-core@lists.openembedded.org
>> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
> 
> 
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core