[Openembedded-architecture] Yocto Compatible 2.0 + signature changes

[Patrick Ohly]

On Wed, 2017-05-10 at 21:03 -0500, Joshua Watt wrote:
> Is it helpful to frame the discussion in terms of what layers are
> actually used for? There seem to be several distinct types of recipes
> that can go into a layer, and they tend to go about things
> differently. I can think of 3 types off the top of my head (but I'm
> sure there are more):

The current yocto-compat-layer.py script distinguishes exactly between
the three types you mentioned.

>  1) Plain recipes - These are all about adding recipes (most of the oe
> layers are this way). For these, not modifying the build make perfect
> sense, since they are about *mechanism* (providing functionality).

The caveat here is the one that Phil mentioned where two layers A and B
have the same recipe. Each layer itself will be "Yocto Compatible 2.0"
against a base configuration like Poky which doesn't have that recipe,
but when adding B to a configuration which already has A, there may be a
change when the recipe from B starts to get used.

In general, testing for "Yocto Compatible 2.0" comprehensively is
difficult. As another example, some layers only change the build for
certain machines, so merely testing with the default MACHINE=qemux86
won't find the differences.

For a BSP layer, I already added tests that iterate through a set of
machines that are specified when starting the tool. The same might also
be necessary for other layers.

>  2) "Distro" recipes - These recipes are about making the *policy*
> decisions that make a distro what it is. It seems like it would be
> very difficult to do this type of thing without making some
> modifications to the build process, unless all recipe files included
> all possible policy options that any distro might want via
> DISTRO_FEATURES, PACKAGECONFIG, etc. (which IMHO is probably not
> actually possible).

It is doable, albeit not as nice as simply throwing a .bbappend into a
distro layer.

>  3) "BSP" recipes - Add hardware functionality. These ones are tricky
> and probably the hardest to pin down. I could easily see a BSP layer
> thinking its a good idea to modify other "plain" recipes to take
> advantage of some fancy hardware acceleration it provides (which can
> honestly make or break an embedded system). I don't know if this isn't
> a *good* practice, but I'm sure it happens.

I think it is bad practice, and perhaps the main motivation for "Yocto
Compatible 2.0". The BSP creator probably doesn't care as long "his"
hardware works fine, but it is a problem for distros which need to
support more than one kind of hardware.

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