On Wed, Jan 25, 2012 at 4:48 AM, Paul Eggleton <[email protected]> wrote: > 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
meta-oe was started to fill in gaps that oe-core would have for existing oe users since oe-core will not have all required functionality and so distros could migrate to using oe-core and not loose the bells and whistles they already have. Plus its an umbrella layer which has many layers underneath. However the problems it sees right now are that there are pieces which could be considered distro specific and ones, the new untested recipes should not be an issue if they are pinned properly. recipes that move our of oe-core I agree should be hosted in a meta-deprecated or somesuch I am happy to move out toolchain bits as well into a separate layer under meta-openembedded umbrella that will clarify it a bit and should not be a big hassle. I think real issue people suffer from is 2 and the duplicate recipes in meta-oe which has different configuration in oe-core. So meta-oe meta-toolchain meta-deprecated could be created now we need to find maintainer for these layers. All said if it was possible to handpick versions from layers and use bitbake -g output pn-depends.dot to generate some manifest so indicate which recipe is being picked from a set of recipes from different layers would be helpful. since there always will be some duplicate recipes no matter what. _______________________________________________ Openembedded-devel mailing list [email protected] http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
