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

[Mark Hatle]

On 6/28/17 11:33 AM, Patrick Ohly wrote:
> On Wed, 2017-06-28 at 11:08 +0200, Mark Hatle wrote:
>> On 6/27/17 5:33 PM, 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.
>>>
>>> However, as this is something that software layers might not be able
>>> to do right away, testing for signature changes in software layers can
>>> be disabled. It's on by default, as that was Richard's
>>> recommendation. Whether that should change needs further discussion as
>>> part of finalizing "Yocto Compatible 2.0".
>>>
>>> As it might still change, the tool now has both a with/without
>>> parameter so that users of the tool can choose the desired behavior
>>> without being affected by future changes to the default.
>>
>> How would you regulate the behavior of a software layer that is doing bbappends
>> or similar to a system provided component.
> 
> By adding a PACKAGECONFIG that is off by default?
> 
> But I haven't tried this and whether it influences task signatures. Do
> you have a specific example?
> 
> Regarding these patches, is it okay to merge them as they are now?
> Without them, we cannot test software layers for signature changes, so
> won't know how much of a problem it would be.
> 
> The tool and "Yocto Compatible 2.0" are work in progress, so there's
> still time to refine it after merging. My motivation for getting them
> merged already now is a) to make the change available to others and b)
> to use the strict version of the check in refkit (where we currently
> satisfy the criteria).
> 

Yes, this was a comment about the commit message, not the technical content of
the patch.

I'm not sure that PACKAGECONFIG can be used to control this type of stuff.  Perhaps?

In many cases, the bbappends seem to add patches or change the way the
compile/install work.  Often these are integration specific for something -- so
there is no 'easy' way to use PACKAGECONFIG to control this.

The only way I can think of is using a PACKAGECONFIG to define a an override.
But as far as I know just adding the evaluation to the overrides and such will
affect the task hashes in some way.

--Mark