On 08/02/2016 02:30 PM, Seebs wrote:
On 2 Aug 2016, at 1:07, Robert Yang wrote:
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.
Hmm. I'm a bit confused by this. Wouldn't the second build also do a
"chmod 0444" on gzip-dbg/version.c? Why is it doing that chmod the first
Because the stat() gets 0644 on ${B}/version.c in the second run, so it
would run chmod 0644 rather than 0444 on gzip-dbg/version.c. And why it
gets 0644 ? pseudo's chmod automatically adds "w" on the real file, so:
if -e gzip-dbg/version.c; then
${B}/version.c = 0444
else
${B}/version.c = 0644
fi
And in the second run, gzip-dbg/version.c is removed and will be recreated,
so that it got 0644.
time and not the second? If it does it the second time, the fact that
the underlying file's mode changed won't matter.
But in this case... While I'm fine with modifying things to track the
Thanks, I will send a patch for it.
file linked-to, it still feels like this is a usage error. Fundamentally,
we're unpacking a file (${B}/version.c), then linking to it, changing
the link in some way, deleting the link, and expecting the original file
to be unchanged. That doesn't seem right to me.
But that is what the real filesystem works without pseudo:
$ touch file1
$ ln file1 file2
$ chmod 777 file2
$ rm -f file2
file1 will be 777 on the real filesystem.
// Robert
-s
--
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.openembedded.org/mailman/listinfo/openembedded-core
