Re: About pseudo's chmod

[Robert Yang <liezhi.yang@windriver.com>]

On 08/02/2016 11:43 AM, Seebs wrote:
> On 1 Aug 2016, at 20:52, Robert Yang wrote:
>
>> And when remove file2, but file1's permission is changed, it should
>> be considered as a bug.
>
> I'm not sure of that. My interpretation would be that hard linking under pseudo
> to files which weren't created under the same pseudo database is
> user error; that's not how the database is intended to work. That said, it's
> pretty trivial to add the things to it.
>
> Although I'd like to know more about the use cases for these, because it
> occurs to me that the qualifier "same pseudo database" points out another

Currently, the problem in oe-core is:

       1) bitbake gzip
       2) Edit rpm-native or package.bbclass to make do_package re-run.
       3) bitbake gzip
       After the first build, build/version.c in gzip-dbg is 0444, but after
       the second build, it will be 0644, this is because do_package does:
       $ ln ${B}/version.c gzip-dbg/version.c,
       $ chmod 0444 gzip-dbg/version.c (it runs chmod 0644 on the real filesystem)
       And in the second build, the gzip-dbg/version.c will be removed and
       created again, so that stat() can't get 0444 but 0644 since
       ${B}/version.c is not tracked by pseudo.

// Robert

> possible failure mode: Would any of those files that are being linked to
> be getting linked to from *more than one* pseudo database? Because if they were,
> that would be a thing I haven't been planning for and I don't know
> whether it'd work sanely.
>
> -s