Re: yocto beagleboard.conf -- should it not go away?

[Richard Purdie <richard.purdie@linuxfoundation.org>]

On Wed, 2012-09-05 at 10:45 -0400, William Mills wrote:
> 
> On 09/05/2012 08:48 AM, Richard Purdie wrote:
> > On Wed, 2012-09-05 at 10:43 +0100, Tomas Frydrych wrote:
> >> On 05/09/12 10:15, Paul Eggleton wrote:
> >>> On Wednesday 05 September 2012 09:49:11 Tomas Frydrych wrote:
> >>> It has been considered witin OE to be best practice to append to BBPATH and
> >>> not prepend, the thinking being that then the search path matches the order of
> >>> the layers listed in bblayers.conf rather than the reverse.
> >>
> >> Then meta-yocto should follow that convention ... and it needs to be
> >> well documented, with the consequence of breaking that convention
> >> explained, and the terrible punishments to come described in great and
> >> sordid detail. Because this needs to be more than a convention, it needs
> >> to be an article of faith.
> >
> > I just want to clarify something here.
> >
> > Its accepted that most layers will append to BBPATH. I do think its
> > acceptable for a distro policy layer to prepend though and this is why
> > meta-yocto does this. I don't remember the exact reason right now but
> > the principle stands.
> 
> So how should we resolve the issue in meta-ti for the denzil/1.2 branch?
> 
> I think the expediency of prepending sounds right to me.  We can shoot 
> for a better fix in 1.3.

I think the problem is in meta-yocto and is hitting a particular subset
of users where people combine meta-yocto and meta-ti.

I'm not sure this can easily be fixed in meta-ti, or that we currently
have a high volume of users mixing those two.

> > The root of the problem is that meta-yocto mixes up policy and hardware
> > support which is bad. It also means its not compliant with the new Yocto
> > Project compliance criteria and hence is not Yocto Project Compatible.
> >
> > Now we've got the compliance criteria sorted out there are some
> > adjustments that need to be made and I will shortly be cleaving
> > meta-yocto into two pieces to resolve this. I hadn't looked at this
> > until now mainly in case there were changes to the criteria.
> >
> > FWIW I think this shows the strength of those criteria as by following
> > them, we'd avoid a real world problem here.
> 
> I'm glad you are thinking of doing this.  I think it sets a good example 
> and is cleaner.
> 
> However we will still need priority or namespace to override the 
> beagleboard definition in the meta-yocto-bsp (or whatever) layer if it 
> contains both the beagleboard reference and the atom-pc.

With the solution, you can just order the meta-ti and meta-yocto-bsp
layers such that the TI layer "wins" and no extra configuration is
necessary. The trouble is that the meta-yocto doesn't allow this at the
moment as things stand.

In many ways this is just part of the learning experience of how to use
and how not to use layers...

Despite the fact we just passed the feature freeze point, I'm going to
ensure we get this fixed for 1.3.

Cheers,

Richard