Re: [PATCH 3/6] yocto-compat-layer.py: apply test_signatures to all layers

[Patrick Ohly <patrick.ohly@intel.com>]

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.