1. Messages
  2. SSTATE corruption

Re: SSTATE corruption

Chuck Wolber
 

Alex is very much correct, you should not see corruption. But I think more detail is in order.

If your distro repository is a "garden variety" set of image recipes and recipe overrides that pull upstream source bundles, then your SSTATE cache should age nicely from release to release.

However, if your source code and associated application files ride along in the same repository as your recipes, or you add your own bbclass functionality, you may want to reconsider keeping SSTATE cache around for too long. There are still some issues to be worked out to make the local file fetcher as reliable as the other fetchers when it comes to keeping your distro buttoned up into one monolithic repository with application level source code trees.

..Ch:W..


On Tue, Mar 22, 2022 at 7:13 AM Alexander Kanavin <alex.kanavin@...> wrote:
No and no.

Alex

On Tue, 22 Mar 2022 at 14:48, Rusty Howell <rustyhowell@...> wrote:
>
> Is the sstate cache sensitive to different releases and or the ordering of the bblayers?   We are upgrading our Yocto-based distro from dunfell to hardknott.  So for a while we will be building our distro on both releases.   Do we need to keep the sstate caches separate for these builds?
>
> Another related question... Does changing the order of the bblayers corrupt the sstate cache (ie require a fresh sstate)?
> Thanks
>
>
>





--
"Perfection must be reached by degrees; she requires the slow hand of time." - Voltaire
Join {yocto@lists.yoctoproject.org to automatically receive all group messages.