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
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
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.
-s
--
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.openembedded.org/mailman/listinfo/openembedded-core
