[OE-core] [PATCH 2/21] Add directory information to the pkgdata files
Paul Eggleton
paul.eggleton at linux.intel.com
Thu May 30 08:29:03 UTC 2013
On Wednesday 29 May 2013 15:44:58 Mark Hatle wrote:
> On 5/29/13 2:59 PM, Phil Blundell wrote:
> > On Wed, 2013-05-29 at 11:30 -0500, Mark Hatle wrote:
> >> It's up to the tooling that are using these files to check if the
> >> directory
> >> exists, if it does not -- then using bitbake -c patch <recipe> will
> >> create it. (even in the sstate-cache case.)
> >
> > I'm not sure whether checking that the directory exists is all that
> > safe; in the shared-sstate scenario I think it's conceivable that the
> > directory might exist but contain something else, or be unreadable due
> > to permissions, or disappear underneath you while you're using it.
> >
> > And, of course, "bitbake -c patch ..." won't necessarily create the same
> > ${S} that you got from pkgdata in that case, it will create it in your
> > local TMPDIR.
>
> On 5/29/13 12:36 PM, Khem Raj wrote:
> > Hi Mark
> >
> > This won't work well when package is populated from sstate is there a way
> > for it to work seamlessly across sstate it might be useful
>
> I was looking at this again. I thought the pkgdata was reconstructed each
> time in the current TMPDIR. I didn't realize it was just restored from the
> sstate-cache. (We've got other patches in layers that trigger pkgdata-like
> files to be generated as well.. and I must have gotten the two confused.)
I think this is new behaviour for 1.4, so that might explain some of the
confusion. Previously the pkgdata generation happened in do_package, but now
that do_rootfs and other places rely upon the presence of pkgdata, it is now a
separate task so it can be accelerated by sstate and do_package doesn't need
to be re-run.
Cheers,
Paul
--
Paul Eggleton
Intel Open Source Technology Centre
More information about the Openembedded-core
mailing list