Thanks! That's a good clarification. Now on other hand, I have experienced a few anomalies that are more at the final image build stage, especially when using RPM feed, and the PR service to auto bump them when rebuilt for dependencies.
The image build recipes must then not have visibility all the way back into the sstate cache, but only as far as the version decorations used in the RPM feed, right? ___ Regards, Darcy Darcy Watkins :: Senior Staff Engineer, Firmware SIERRA WIRELESS Direct +1 604 233 7989<tel:+1%20604%20233%207989> :: Fax +1 604 231 1109<tel:+1%20604%20231%201109> :: Main +1 604 231 1100<tel:+1%20604%20231%201100> 13811 Wireless Way :: Richmond, BC Canada V6V 3A4<x-apple-data-detectors://3/1> [M4] dwatk...@sierrawireless.com<mailto:dwatk...@sierrawireless.com> :: www.sierrawireless.com<http://www.sierrawireless.com/> :: www.inmotiontechnology.com<http://www.inmotiontechnology.com/> On May 20, 2017, at 8:54 AM, Khem Raj <raj.k...@gmail.com<mailto:raj.k...@gmail.com>> wrote: On Sat, May 20, 2017 at 8:16 AM, Darcy Watkins <dwatk...@sierrawireless.com<mailto:dwatk...@sierrawireless.com>> wrote: Are you saying that the sstate cache is smart enough to handle exact same package for same arch but just built using different layer stack? (Say one case builds package A with a bbappend, but the other uses a bbappend from a different layer, and say they are at same bbappend revision). yes it should be, since it checksums the variables which are effective during build of a given package.
-- _______________________________________________ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
