[OE-core] How to overlay files/fs-perms.txt?
Mark Hatle
mark.hatle at windriver.com
Tue Oct 11 19:03:03 UTC 2011
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 at 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 at lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
More information about the Openembedded-core
mailing list