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]" 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... 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? 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. 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? ;-} -- Best Regards, Patrick Ohly The content of this message is my personal opinion only and although I am an employee of Intel, the statements I make here in no way represent Intel's position on the issue, nor am I authorized to speak on behalf of Intel on this matter. -- _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
