Re: [OE-core] Core workflow: sstate for all, bblock/bbunlock, tools for why is sstate not being reused?

[Richard Purdie <richard.purdie@linuxfoundation.org>]

On Mon, 2024-02-05 at 21:35 +0100, Alexander Kanavin wrote:
> 2. Something that didn't occur to me until now: simply copying over
> sstate to another location doesn't guarantee that it's going to be
> used, if that sstate needs to be discovered via hash equivalency
> database. There are two options here:
> 
> - lock down sstate signatures to what is available (esdks take this
> route, and get away with it because of restricted devtool-only
> functionality and hidden layers that never change)
> 
> - export the hash equivalency database into something human readable,
> and placed into the bundle, and then import it back when the bundle is
> unpacked and set up. As far as I understand currently there's no code
> for this. I'd find it useful in general, as effects of hash
> equivalency can be tricky to grasp, and being able to look at the
> database in a human readable format goes a long way towards
> understanding how it all fits together. There may be other use cases
> where you'd want to move the content of the database between build
> machines. I'd like to get Joshua's take on this, did I misunderstand
> this completely?

You don't misunderstand, this is an issue.

The good news is that the hashes needed will be in
cache/bb_unihashes.dat. The eSDK code saves and restores that to ensure
things all work out ok.

It isn't human readable but could be translated easily enough.

Cheers,

Richard