[Openembedded-architecture] Yocto Compatible 2.0 + signature changes

[Joshua Watt]

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):
 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).
 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).
 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 a lot of layers can (and do) try to simultaneously house
multiple different types of recipes at once, which IHMO causes some
confusion. I think this might also be where some of the concern comes
from, since a layer that mixes any of the three types
 of recipes might have a hard time being "Yocto 2.0 compatible"

Maybe the solution is to say that Yocto 2.0 compatible means not
modifying the build in which case I might expect the BSP and Distro
recipes to split into a non-compliant layer (which might not be a bad
thing), or maybe being 2.0 compatible can vary depending on the
purpose of the layer (if we can fix rules for each type), or maybe
some other option is better.

Joshua Watt

On Wed, May 10, 2017 at 4:36 PM, Phil Blundell <pb at pbcl.net> wrote:
> On Wed, 2017-05-10 at 16:41 -0400, Trevor Woerner wrote:
>> If simply adding a Yocto Compatible 2.0 layer to a build doesn't
>> cause
>> any of its *bbappends to affect the build by default, but simply
>> adding any other (presumably non Yocto Compatible 2.0) layer to a
>> build has the potential to affect the build simply by virtue of
>> having
>> added the layer, wouldn't that be horribly confusing for users?
>
> Well, the status quo is that some layers do modify the build and others
> don't.  Adding some sort of branding to indicate which ones are known
> not to have such effects (given a known set of other layers in use)
> seems like a positive step and I don't really understand how this would
> be "horribly confusing".
>
>> Shouldn't this sort of complete reversal of policy regarding layers
>> be
>> something that's enforced by the tool (bitbake) so that either all
>> layers affect the build simply by virtual of being added, or they
>> don't?
>
> I don't entirely understand your comment about a complete reversal.
> But that aside, no, I don't think it would be desirable for bitbake to
> attempt to police this, nor am I entirely convinced that it is
> technically feasible for bitbake to do that in the general case.
> Consider:
>
> 1. If layer A and layer B both include different versions of the same
> recipe then bitbake has to pick one or other of them.  If a user was
> previously including one of these layers and then adds the other one
> then there is no way to guarantee that bitbake will make the same
> choice it did before.  So in the most general case, the only way to
> ensure that a layer cannot conflict with any other layer is for it
> either to contain no recipes, or to have an infinitely low preference
> such that it is never selected.  And the latter of these two approaches
> is not scalable to more than one layer, so the logical conclusion would
> be that all layers must contain no recipes.  This does not seem like a
> useful conclusion in the real world :-}
>
> 2. Some users, including me, have layers for internal use that contain
> .bbappends whose whole purpose is to modify the behaviour of recipes in
> other layers (generally oe-core).  It would be annoying if such things
> were outlawed or required a lot of extra contortion.
>
> p.
>
> _______________________________________________
> Openembedded-architecture mailing list
> Openembedded-architecture at lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-architecture