[yocto] yocto beagleboard.conf -- should it not go away?

Bruce Ashfield bruce.ashfield at gmail.com
Mon Sep 3 14:08:44 PDT 2012


On Mon, Sep 3, 2012 at 4:55 PM, Tomas Frydrych
<tf+lists.yocto at r-finger.com> wrote:
> Hi,
>
> On 03/09/12 21:15, Bruce Ashfield wrote:
>> On Mon, Sep 3, 2012 at 4:06 PM, Tomas Frydrych
>> So we fix the configuration of the layers ..
>
> I expect this is not actually that trivial. I think the only way to do
> this is properly is for the layer priorities to be respected by all
> files in the layer, not just the bb files. No idea how involved that
> change would be, or what the side effects would be.

This is a very common layering scenario, so if the system as a whole can't
handle it, that's a bigger problem. If two layers can't have a board with the
same name, and there's no way for them to work together without tweaking
multiple files in the layer, I'd say that's a problem and one that should
be fixed. Otherwise, a OSV (or someone else) can never hope to extend
anything from a yocto layer.

That being said, taking a step back, what are you trying to get out of
meta-yocto in this scenario ? oe-core + meta-ti is probably what you
should be using.

>
>
>> and meta-ti was supposed to work properly with meta-yocto last I heard.
>
> If properly means 'out of the box', then no; the two layers can be made
> to work together, but it's fairly clear that nobody comprehensively
> tests that combination at the moment.

see above. I misspoke. I don't think there's an intent to make meta-yocto
and meta-ti work together, but oe-core + meta-ti, that's the combo that
makes sense.

>
>
>> The meta-yocto layer beagleboard configuration is a hardware ARM reference, that
>> uses the linux-yocto kernel (policy and version) and is used for the
>> project QA on hardware.
>
> I am all for QA, but in this instance your QA procedure breaks things
> for the end user. Could you not just call it something else, e.g.,
> yocto-qa-arm-reference.conf?

Hmmm. I'd say no to that, because the system should handle something like this,
and dancing around the real problem with varying names of BSPs outside of the
name of the board they actually support, isn't a solution.

Cheers,

Bruce

>
> Tomas
> _______________________________________________
> yocto mailing list
> yocto at yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto



-- 
"Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end"



More information about the yocto mailing list