[OE-core] [PATCH] bitbake.conf: point PERSISTENT_DIR outside TMPDIR

[Richard Purdie]

On Fri, 2011-03-04 at 15:57 +0100, Martin Jansa wrote:
> On Fri, Mar 04, 2011 at 02:01:26PM +0000, Richard Purdie wrote:
> > On Fri, 2011-03-04 at 11:40 +0100, Martin Jansa wrote:
> > > * sanity check warning user that he still has peristent cache in old location
> > > * similar patch was sent to OE, to keep PERSISTENT_DIR location consistent
> > >   http://lists.linuxtogo.org/pipermail/openembedded-devel/2011-March/030623.html
> > > 
> > > Signed-off-by: Martin Jansa <Martin.Jansa at gmail.com>
> > > ---
> > >  meta/classes/sanity.bbclass |    8 ++++++++
> > >  meta/conf/bitbake.conf      |    2 +-
> > >  meta/conf/sanity.conf       |    1 +
> > >  3 files changed, 10 insertions(+), 1 deletions(-)
> > 
> > When I saw this on the OE list, I'd assumed you'd done what Poky had
> > done, I've just realised you're moving this file to TOPDIR instead of
> > TMPDIR.
> > 
> > My big concern here is that we really shouldn't be writing to data to
> > the conf directory as its not what the user expects.
> > 
> > I say this knowing the raft of usability problems we've had every time
> > we take something outside of TMPDIR as users have the expectation that
> > deleting tmp wipes out all stored state and rebuilds. Having this file
> > hidden in the conf directory breaks that expectation. Note there are
> > only two things we place outside of TMPDIR, downloads and sstate data.
> > Even things like buildstats which you might want to preserve over
> > different builds are still inside TMPDIR.
> > 
> > Can we put it in cache as a top level file rather than machine specific?
> 
> And one more question from #oe to this topic:
> ./oe-2011-02-25:14:49 < JaMa> RP: I wonder if bb_codeparser.dat from
> bitbake rev 4b7aab109f746ad9be2699c0fb6f4a4e65d65936 should be in shared
> PERSISTENT_DIR or machine specific CACHE dir, what do you think?

The bb_codeparser.dat file doesn't need to be machine specific. It
doesn't need to be persistent either however. You can delete it and
whilst you'll hit a little extra parse time, no information is lost.

Cheers,

Richard