[bitbake-devel] [PATCH] data/siggen: Switch md5 -> sha256

richard.purdie at linuxfoundation.org richard.purdie at linuxfoundation.org
Wed Jul 24 14:19:48 UTC 2019


On Wed, 2019-07-24 at 10:11 +0100, Mike Crowe wrote:
> We make use of the recipe name in our sstate cache pruning script,
> since some recipes have more churn and we expire them more quickly.
> That shouldn't be a problem as long as the recipe name is kept in
> preference to the version.

Lets get the abstraction, then we can discuss which pieces make most
sense and have which priority.

> > > So the same truncation when matching, and it should be safe.  The
> > > recipe,
> > > version ... task bit is nice to have for a human reader, but I
> > > don't
> > > think it's
> > > actually needed by the system itself.
> > > 
> > > This should avoid any collisions and keep the maximum information
> > > that will fit
> > > in the filename(s).
> > 
> > In some ways regardless of what we do, we need to abstract it so
> > that
> > we have one function generating the filenames.
> > 
> > So yes, think we need a patch which abstracts the filename
> > generation.
> > It needs to be able to truncate elements of the constructed name
> > other
> > than the hash. I do prefer truncating the other elements than
> > changing
> > the hash.
> 
> If we're going to keep the 64-character SHA-256 hash and instead
> elide parts of the sstate filenames, then I think only sstate.bbclass
> needs to change, so this isn't a Bitbake issue and we should probably
> move this thread it openembedded-core.
> 
> Or perhaps I'm misunderstanding your suggestion.

No, this probably becomes an OE-Core issue. Keep in mind that some code
does glob on these names though iirc so we'll have to consider those
bits too.

Cheers,

Richard



More information about the bitbake-devel mailing list