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

[Patrick Ohly]

On Mon, 2017-05-29 at 13:14 -0700, Christopher Larson wrote:
> 
> On Mon, May 29, 2017 at 12:26 PM, Aníbal Limón
> <anibal.limon at linux.intel.com> wrote:
>         >
>         > 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.
> 
> Currently, if you add a high priority layer with an older version
> recipe, it will change the default selected recipe, lacking a
> PREFERRED_VERSION. You can’t use DEFAULT_PREFERENCE to make the new
> old version of a recipe not be used, since bitbake treats layer
> priority as more important than default preference, so adding a .inc
> won’t do much good, since you can’t make the recipe not be preferred
> by default without a preferred version set to the current oe-core
> version. You could add such a line to the layer.conf, but then you’re
> hardcoding the oe-core recipe version into a separate layer, which is
> pretty ugly. I don’t htink we should be enforcing this signature
> change without resolving this.

The key question is whether overriding existing recipes implicitly
merely by adding a layer is considered acceptable. Any opinions about
that?

We agree that changing via .bbappend unconditionally is bad, even for a
software layer, right?

That means that the signature check must be applied, but with an
exception for wholesale recipe replacements. I can think of one
solution, and that is to artificially lower the priority of the
collections in the new layer so that the recipes in it cannot override
the ones in the base configuration anymore. But this is kind of a hack
and might lead to broken world builds (for example, the layer overrides
recipe A with a version which adds an RPROVIDES foo, and another recipe
B in the layer RDEPENDS on foo).

The alternative would be to do a deep dive into the signature diff and
filter out those changes which are caused by a replaced recipe. This
could be fairly tricky to implement, in particular as these changes then
also affect all recipes depending on the replace recipe. The code behind
bitbake-diffsigs has known limitations regarding recursively identifying
changes [1], so this probably would have to be solved first.

[1] https://bugzilla.yoctoproject.org/show_bug.cgi?id=6428#c4

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