Re: [OE-core] Space optimizations in kirkstone and scarthgap for sstate objects

[Mikko Rapeli <mikko.rapeli@linaro.org>]

Hi,

On Thu, Nov 21, 2024 at 10:41:29AM +0000, Richard Purdie via lists.openembedded.org wrote:
> We've been trying to resolve some of our sstate CDN issues and one
> thing causing us big headaches are large sstate files. By far the worst
> offenders are webkitgtk and llvm.
> 
> In master (and in styhead) we have these:
> 
> https://git.yoctoproject.org/poky/commit/?id=d9066258a1e48e75cf814fb0940ac420bcdd6e99
> https://git.yoctoproject.org/poky/commit/?id=aca8acceb87e568115da9696732e915d91da9652
> https://git.yoctoproject.org/poky/commit/?id=1d8d9b1f87b21af36d9c328132f71c528eefd5b0
> 
> which did significantly reduce the size of the output. Unfortunately I
> made the first two work with changes to DEBUG_LEVELFLAG which are not
> suited for backporting:
> 
> https://git.yoctoproject.org/poky/commit/?id=1cf0974ad242f7eb2815a4ef0e3e5b6507ca56ea
> https://git.yoctoproject.org/poky/commit/?id=ae4ec59b3eff85aaa1cfe914a134e56e1d125744
> 
> I do think we should apply a similar tweak to kirkstone and scarthgap
> though. The third patch above shouldbackport. We should be able to do
> something equivalent for llvm. Any thoughts?
> 
> Michael obtained some sstate size info which I've shared below. You can
> tell the age by the sstate version number (10, 12 and 14 are kirkstone,
> scarthgap and styhead/master) and the recipe versions.

Can similar changes be done via the CI build scripts in the affected branches,
without modifying poky?

I would not mind breaking stable rules when it's about keeping upstream
infrastructure sane and running. Details can be documented to users if they
are impacted and need to revert those changes in their configuration.

Would be nice to know what kind of issues these are in detail and what is the CDN
implementation.

Cheers,

-Mikko