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

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

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.
> 
> 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