[Openembedded-architecture] Yocto Compatible 2.0 + signature changes

[Trevor Woerner]

I've re-read these emails carefully and I see where my confusion came in.

First off I had never heard of conditional bbappends and am surprised
to learn of them. I've seen bbappends being applied conditionally with
respect to BSP layers, because sometimes a recipe doesn't build for a
specific target unless a target-specific patch is applied (this
usually means the code has, say, assembly language mixed in, and this
assembly needs to be re-written or removed in order to compile for
another target). But in this specific case the bbappend is required
for a build to succeed and no action on the user's part is required;
the bbappend either applies or it doesn't and it's all handled
automagically. The user doesn't have to do anything other than to
select the right MACHINE.

I thought, initially, that Patrick was proposing a mechanism by-which
the bbappends of Yocto Compatible 2.0 layers would not affect builds
without explicit action on the user's part. I didn't realize the
situation is the reverse: a layer can only be considered compatible if
it exhibits this behaviour.

So maybe you think it's crazy that I've never heard of conditional
bbappends? Looking at the Yocto documentation:
http://www.yoctoproject.org/docs/latest/mega-manual/mega-manual.html#yocto-project-terms

The first project term is: "Append files":

"Information in append files extends or overrides the information in
the similarly-named recipe file. For an example of an append file in
use, see the "Using .bbappend Files" section."

Nothing about "conditional" application. So, then clicking the link to
the "using .bbappend files" section:
http://www.yoctoproject.org/docs/latest/mega-manual/mega-manual.html#using-bbappend-files

"A .bbappend file allows your layer to make additions or changes to
the content of another layer's recipe without having to copy the other
recipe into your layer. Your .bbappend file resides in your layer,
while the main .bb recipe file to which you are appending Metadata
resides in a different layer."

Again reading through the entire description of how bbappends works
mentions nothing about the conditional application of bbappends. There
is no "bbappends *might* extend or override a recipe" or "bbappends
*may* extend or override a recipe". bbappends make additions to
recipes. If a layer has a bbappends, I expect it to affect the build.
And there's certainly nothing about "bbappends only affects your build
if you then make these changes/additions to your local.conf". There's
absolutely nothing saying "1) create a bbappend 2) enable the bbappend
by taking these explicit steps".

It's true, however, that I'm not as familiar with the guts of bitbake
etc as other are. And it is true that I tend to use OE to take
openembedded-core + a BSP layer and go from there. I don't tend to get
into all the fancy stuff other people do and I don't have the depth of
experience others have. So it's not entirely crazy to think that I've
never heard of conditional bbappends and I do think it might be
confusing to some people when some bbappends apply automatically and
others don't, and the only way to tell the difference is to examine
each line of a bbappend to determine how it will behave.

So in all my experience up to now, the presence of a bbappend means it
will get applied and affect the build, unless it's a CPU-specific
patch in which case the override mechanism takes care of the details
for me automagically (i.e. no explicit action on the part of the
user). Moving to an accreditation system whereby layer authors are
encouraged to write bbappends that won't be applied automatically
unless the user takes specific explicit steps to enable the bbappend,
I think, will be confusing because now some layers will act this way
and other layers won't. Especially since all of this will rely on the
skills of the writer of the bbappend and on the review phase to catch
all such issues.