[OE-core] [PATCH] Revert "kmod: Use base_libdir for installing libkmod"

Phil Blundell philb at gnu.org
Thu May 17 22:22:51 UTC 2012


On Thu, 2012-05-17 at 18:51 -0300, Otavio Salvador wrote:
> It is important to state that if OE-Core breaks Meta-OE this is
> crticial. It is not Yocto that people use and many active contributors
> use Meta-OE so it is important and critical to that people. Seems more
> health to the project to give the deserved value to Meta-OE instead of
> badmouth it...

No doubt meta-oe's welfare is indeed critical to those who use it, but
there is a substantial population of oe-core users who don't.

Without wishing to badmouth meta-oe too much, I do get the impression
that its relationship with oe-core is based more on taking than on
giving, and also that meta-oe seems a bit unclear about what exactly its
own mission is.  On the one hand it seems to try to be a sort of
unofficial mod for oe-core which adds newer/older/different versions of
some recipes and adjusts features in others.  On the other hand it seems
to be a repository for recipes which are of general interest but not
quite "core" enough to be in oe-core.  And on the third hand, there
seems to be a view (as Tom alluded to in this thread) that meta-oe
should serve as some sort of staging area for changes which are
ultimately intended for oe-core but perhaps not quite stable enough yet.
As Paul mentioned, the combination of these three things is somewhat
toxic. 

Personally I would like to see the meta-oe folks make a bit more of an
effort to contribute worthwhile improvements back to oe-core (and/or put
them in other layers, as seems to be happening with the systemd bits)
rather than just keeping them as part of the meta-oe monolith
indefinitely.  And, in parallel with that, I think it would make sense
to split meta-oe into three or maybe more separate layers: one which is
purely a collection of "extra" recipes, one which contains all the
policy changes that meta-oe wishes to make compared to what's in
oe-core, and one which is a sort of "oe-core-next", containing changes
which are theoretically candidates for merging into oe-core but for
whatever reason are not quite ready to submit.

p.






More information about the Openembedded-core mailing list