[Openembedded-architecture] Yocto Compatible 2.0 + signature changes

[Joshua Watt]

Ok, I think I'm understanding this problem better (and that my
previous e-mail probably wasn't all that helpful).

I think that one issue with the DISTRO_FEATURES/OVERRIDES mechanisms
discussed might be the complication of simply writing a recipe
correctly (as I think some people may have hinted at). Could this
possible be solved with a more organizational approach? What if there
were (is?) some way for this to be solved organizationally? Perhaps
along these lines:

 # Add our recipes that don't change the signatures
 BBFILES += "${LAYERDIR}/recipes-*/*/*.bb ${LAYERDIR}/recipes-*/*/*.bbappend"
 # Add the other appends that will change signatures...
 # The user will have to ensure the proper overrides are set
 BBFILES += "${LAYERDIR}/%OVERRIDE%/recipes-*/*/*.bbappend"

In this scheme, bitbake would expand %OVERRIDE% with the values from
OVERRIDES (sort of like it does with FILESPATH). In this manner you
can continue to write bbappend as you are used to, and use the
filesystem organization to conditionally apply the bbappends based on
the overrides. There are probably other similar mechanism that would
work better, this one is mostly for illustration.

This has the potential disadvantage of exploding the BBFILES search
path. I don't know enough about bitbake internals to know if that is a
problem.

By using a token in the path, yocto-compat-layer.py can probably even
do some magic to make sure that recipes with overrides in their path
do indeed change the signature (otherwise, why have them there?),
giving an extra level of QA.

Additionally, I think this also has the advantage that people are used
to seeing overrides in paths, so it's not that much of a stretch to
figure out what this is doing. I suppose the same argument could be
made that people should be used to seeing overrides in a recipe, but
I'm not sure that it would be immediately obvious that the smattering
of overrides servers the purpose of preventing signature changes.

It seems like such a mechanism could prevent the need to "backfill"
the OVERRIDES from the DISTRO_FEATURES (or vis-versa).