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

Patrick Ohly patrick.ohly at intel.com
Wed Jun 28 09:33:59 UTC 2017


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).

-- 
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.






More information about the Openembedded-core mailing list