On 05/29/2017 02:18 PM, Patrick Ohly wrote: > On Mon, 2017-05-29 at 11:13 -0500, Aníbal Limón wrote: >> On 05/29/2017 10:32 AM, Patrick Ohly wrote: >>> Software layers were previously allowed to change signatures, but >>> that's not desired for those layers either. The rule that a layer >>> which is "Yocto Compatible 2.0" must not change signatures unless >>> explicitly requested holds for all kinds of layers. >> >> If i understand correctly now a software layer can't change a signature >> but how do we handle this?, currently if a software layer is added and >> has bbappends or newer version of a recipe the signature will change. > > We've touched on this topic in the "[Openembedded-architecture] Yocto > Compatible 2.0 + signature changes" mail thread. I had asked about > software layers and Richard said "I do think we need to do this [strict > signature check also for software layers]"
Sorry, i did not see that thread, i need to be more aware on the arch ML. :) > > For .bbappends, the solution from that mail thread is to turn > DISTRO_FEATURES into overrides and make changes in the .bbappend depend > on that, or include the .bbappend code only for certain features. That > reminds me, I still need to turn my prototype code for that into a > specific patch for bitbake.conf... Yes, sounds good to me. > > Changing software versions is indeed a bit more problematic. One could > argue that layers shouldn't fight over who provides a certain recipe in > the first place. If they do, perhaps the "additional layers" (= the ones > with lower priority) need to provide explicit .inc files with > PREFERRED_VERSION assignments without which the overriding recipes > aren't used? Yes, so in this case will need to set automatically the preferred versions to oe-core recipes, and then let the distro layer to change the preferred version in this way when test a distro layer with oe-core the signatures not will change only when add the combo of distro layer + software layer. > > Also remember that this is only a problem for layers who want to be > "Yocto Compatible 2.0". Other, private layers can simply ignore the > rules and do what needs to be done. Agree, > > Alternatively, we can make the stricter checking of software layers > optional in the tool. Not sure what that'll mean for the "Yocto > Compatible 2.0" - all layers are created compatible, some more than > others? ;-} If we have the decision to include this checking in software layers, i will go to make it as a default mode with the option to disable it. Cheers, Anibal >
signature.asc
Description: OpenPGP digital signature
-- _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core