[oe] [PATCH (v2)] Reverse the order of OVERRIDES

Richard Purdie rpurdie at rpsys.net
Wed Nov 10 14:26:56 UTC 2010


On Fri, 2010-10-15 at 12:44 -0700, Chris Larson wrote:
> On Fri, Oct 15, 2010 at 12:37 PM, Koen Kooi <k.kooi at student.utwente.nl>wrote:
> 
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > On 15-10-10 17:41, Chris Larson wrote:
> > > From: Chris Larson <chris_larson at mentor.com>
> > >
> > > Given the current implementation of OVERRIDES in bitbake, the variable is
> > > expected to contain elements in the order least specific to most
> > specific,
> > > however, our current usage of it does not match that.  As one example,
> > "local"
> > > is supposed to always be the most specific override, yet currently it's
> > the
> > > least specific.  As another example, currently the target architecture is
> > seen
> > > as more specific than the machine, which is also clearly wrong.
> > >
> > > Big thanks to Chase Maupin for investigating and identifying this long
> > > standing issue.
> > >
> > > It becomes clear that a reversal of the current value will bring us to a
> > more
> > > sane behavior, and avoids the need for the dual overrides hack mentioned
> > in
> > > the comments, so this implements this reversal, and drops the unnecessary
> > and
> > > confusing comments.
> > >
> > > This also introduces a MACHINE_OVERRIDES variable as a generic mechanism
> > to
> > > inject overrides elements which are more specific than the distro but
> > less
> > > specific than the machine, which is where things like MACHINE_CLASS or
> > > SOC_FAMILY or the like would go.  This variable is *space* separated, to
> > make
> > > it easier and more convenient to assemble the variable incrementally.
> > >
> > > Reported-by: Chase Maupin <chase.maupin at ti.com>
> > > Signed-off-by: Chris Larson <chris_larson at mentor.com>
> >
> > Acked-by: Koen Kooi <k-kooi at ti.com>
> >
> 
> This is now in master -- thanks to all for the acks, review, comments -- let
> me know if any problems result from this.

You do realise the damage this potentially causes for compatibility of
metadata between OE and Poky?

This change is pretty serious and potentially alters the handling of any
double override. Poky uses them a bit more extensively than OE does. Its
effectively an architecture change to OE yet no discussion was had at
any TSC meeting :(.

I even asked about this a while back and was *told* that "local" was
meant to be weak, I therefore added a strong version to Poky, in the
spirit of maintaining compatibility.

Richard








More information about the Openembedded-devel mailing list