Re: Over-pruning the sstate cache

[Mike Crowe <mac@mcrowe.com>]

On Wednesday 13 April 2016 at 10:47:13 -0300, Otavio Salvador wrote:
> On Tue, Apr 12, 2016 at 5:50 PM, Richard Purdie
> <richard.purdie@linuxfoundation.org> wrote:
> > On Tue, 2016-04-12 at 19:51 +0100, Mike Crowe wrote:
> >> On Tuesday 29 March 2016 at 15:11:10 +0100, Richard Purdie wrote:
> >> > On Tue, 2016-03-29 at 13:56 +0100, Mike Crowe wrote:
> >> > > 80b3974081c4a8c604e23982a6db8fb32c616058 implies that at least
> >> > > some
> >> > > people
> >> > > are pruning the sstate cache based on file access time.
> >> > >
> >> > > Is there a recommended way to ensure that all the sstate cache
> >> > > files
> >> > > are
> >> > > touched, even those that are not actually required to build the
> >> > > image
> >> > > currently due to task optimisation?
> >> > >
> >> > > Does anyone have any better ideas?
> >> >
> >> > generate the "locked-sigs" inc file (bitbake XXX -S none) and then
> >> > with
> >> > a script touch all the objects listed in that file?
> >>
> >> I'm most of the way through writing a script to do this. I've
> >> discovered
> >> that the sstate filenames contain bits that aren't in the locked-sigs
> >> file
> >> such as ${PV}, ${PR}, ${TARGET_VENDOR}, ${TARGET_OS},
> >> ${SSTATE_VERSION}.
> >> The hash is the important bit for identifying the file uniquely so
> >> these
> >> bits can either be hard coded or wildcarded as appropriate.
> >>
> >> There's also the need to apply native OS name prefix for native
> >> packages.
> >>
> >> Is there a a way of getting hold of those bits so I can avoid the
> >> wildcards?
> >
> > In theory the key part is the hash, all the other pieces are there just
> > to make human understandable filenames/layout (and would be encoded
> > into the hash in most cases). Whilst we could generate that info, I'm
> > not sure it would help much since the hashes should uniquely identify
> > the files?
> 
> Couldn't this to be done, similar to the fetchall task?

That's the sort of thing I was thinking of with my "all_populate_sysroot"
task in my original question.

But, I've a working script using Richard's method now. I'll share it once
I've tested it a bit more.

Mike.