[Openembedded-architecture] Yocto Compatible 2.0 + signature changes

[Patrick Ohly]

On Tue, 2017-05-09 at 11:00 +0100, Richard Purdie wrote:
> On Tue, 2017-05-09 at 11:41 +0200, Patrick Ohly wrote:
> > On Tue, 2017-05-09 at 10:17 +0100, Richard Purdie wrote:
> > > 
> > > On Tue, 2017-05-09 at 11:08 +0200, Patrick Ohly wrote:
> > > > 
> > > > I've done something similar when enabling Smack. The downside was
> > > > that one also wants a corresponding DISTRO_FEATURE, and then both
> > > > overrides and DISTRO_FEATURE have to be set consistently. It
> > > > isn't
> > > > possible to just set the DISTRO_FEATURE and then set the override
> > > > based on that automatically, so the traditional way of choosing
> > > > distro features no longer works.
> > > I'm not saying this is a good idea or that we should do this but I
> > > suspect it is at least possible:
> > > 
> > > DISTROOVERRIDES .= "${@bb.utils.contains('DISTRO_FEATURES',
> > > 'refkit-firewall', ':refkit-firewall', '', d)}"
> > How does that address the (potential?) cyclic dependency of
> > "DISTRO_FEATURES depends on OVERRIDES which depends on
> > DISTRO_FEATURES"?
> 
> You either set this feature in overrides or in distro_features and the
> other is set based on that. You have to choose to make this configured
> based on one or the other and if you do that it shouldn't cyclical?

I was wondering more about some other, unrelated distro feature and how
the code would then expand either OVERRIDES or DISTRO_FEATURES.

Consider this local.conf example:

        DISTROOVERRIDES .= "${@bb.utils.contains('DISTRO_FEATURES', 'foo', ':foo', '', d)}"
        MACHINE = "intel-corei7-64"
        DISTRO_FEATURES_append_intel-corei7-64 = "bar"

This could have led to an infinite recursion. In practice, the current
code already seems to detect the cycle and aborts expanding. But "bar"
does not get added to DISTRO_FEATURES either:

        $ bitbake -e  | grep ^DISTRO_FEATURES= | grep -w bar | wc -l
        0

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