Splitting meta-oe

[Paul Eggleton <paul.eggleton@linux.intel.com>]

Hi all,

The meta-oe layer [1] is becoming the home for additional recipes that we miss 
from OE-Classic that don't have another obvious layer to go into, and this is 
a good thing. However I think that meta-oe is already in a state where quite a 
few people feel the new structure is not working for them.

As I see it, meta-oe is trying provide the following:

 1) Additional recipes that are not in OE-Core

 2) Additional functionality for OE-Core recipes that we can't enable in OE-
Core itself (e.g. enabling postgres support in Qt) - mostly just a side-effect 
of #1

 3) A place to preserve old versions of recipes that have been removed from 
OE-Core in favour of newer versions

 4) Newer less-well tested versions of recipes

I think what most people want when they enable meta-oe in their layer 
configuration is #1, and it's probably OK to get #2 along with it. They do not 
however expect versions of toolchains, eglibc or other fairly fundamental bits 
and pieces that might cause their build to fail when everything worked fine 
just building with OE-Core (#4). Equally I expect there will be some people 
who want just #3 and nothing else.

I understand there is significant value in providing all of these things, I 
just think we shouldn't be trying to do them all in one largely indivisible 
layer. In our new layer structure we should be able to find a way to split the 
metadata so that people who want any combination can still have what we have 
in meta-oe today, and yet those who just want one of them don't get unexpected 
build failures or older/newer versions being built.

Thoughts?

Cheers,
Paul

[1] http://cgit.openembedded.org/meta-openembedded/tree/meta-oe

-- 

Paul Eggleton
Intel Open Source Technology Centre