Re: [PATCH (v2)] Reverse the order of OVERRIDES

[Tom Rini <tom_rini@mentor.com>]

Richard Purdie wrote:
> 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@student.utwente.nl>wrote:
>>
>>> -----BEGIN PGP SIGNED MESSAGE-----
>>> Hash: SHA1
>>>
>>> On 15-10-10 17:41, Chris Larson wrote:
>>>> From: Chris Larson <chris_larson@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@ti.com>
>>>> Signed-off-by: Chris Larson <chris_larson@mentor.com>
>>> Acked-by: Koen Kooi <k-kooi@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.
> 

(a) Eeep! and (b) That's pretty much the opposite of what the rest of 
the thread / discussion was, which is to say "local is supposed to be 
the final winner, why isn't it?"

Now... what do we do here?

-- 
Tom Rini
Mentor Graphics Corporation