On Sat, May 20, 2017 at 10:04 AM, Darcy Watkins <dwatk...@sierrawireless.com> wrote: > 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?
They infact should. Since every image you are building follows exact same process. It will recursively go down to package granularity and PR is just one of inputs to determine rebuilding if its not automatically set, if its set automatically then it will actually be incremented for you > > > ___ > > Regards, > > > > Darcy > > > > Darcy Watkins :: Senior Staff Engineer, Firmware > > > > SIERRA WIRELESS > > Direct +1 604 233 7989 :: Fax +1 604 231 1109 :: Main +1 604 231 > 1100 > > 13811 Wireless Way :: Richmond, BC Canada V6V 3A4 > > [M4] > > dwatk...@sierrawireless.com :: www.sierrawireless.com :: > www.inmotiontechnology.com > > > > > On May 20, 2017, at 8:54 AM, Khem Raj <raj.k...@gmail.com> wrote: > > On Sat, May 20, 2017 at 8:16 AM, Darcy Watkins > <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
