[oe] Populating meta-oe with new patches on oe.dev

Phil Blundell philb at gnu.org
Thu Jul 28 09:37:40 UTC 2011


On Tue, 2011-07-26 at 18:11 +0100, Paul Eggleton wrote:
> On Sunday 17 July 2011 17:12:51 Paul Menzel wrote:
> > 3. I find the `recipe-*section*/` directories difficult to handle to
> > finding a recipe. Before I would use `recipe/` and then tab completion
> > and now I have to search for it. Are others uncomfortable with this?
> 
> I'm used to it now but it did feel a bit strange to begin with. 

I've been using oe-core for a while now and I do still find it a bit
annoying when you have to search in multiple directories to try to find
the recipe that you're looking for.  In some cases it's obvious and
there's no problem (eg it's fairly easy to guess that gcc would be in
devtools) but the split between some of the other directories
(particularly -core/-support/-extended/-connectivity and
-graphics/-gnome/-sato) often seems a bit arbitrary.

However, emacs seems to be able to do tab completion across multiple
levels of hierarchy nowadays, so I can just type
"meta/recipes-/net-tools<TAB>" and it automatically figures out that
recipes-extended is the right thing.  So in practice this is not too big
a deal for me most of the time.  And I agree that having a single
massive directory of recipes is not such a great thing either, so the
current arrangement probably is a reasonable compromise.

> > 4. What images are available in/for oe-core/meta-openembedded? I liked
> > for example `minimal{,-uclibc}`? `find . -name minimal*` in `oe-core` or
> > `meta-oe` did not give any result. Not to mention the images for
> > BeagleBoard or `micro-image` for the recently sent patches for payload
> > creation for coreboot

micro-image itself doesn't currently exist for the oe-core world.
However, micro-base-image (which always seemed the more useful one) is
in the meta-micro layer, see:

http://cgit.openembedded.org/cgit.cgi/meta-micro/tree/recipes/images

If you wanted to submit a patch to reinstate micro-image, with a
suitable rationale for why it's useful, then that would be welcome.

p.






More information about the Openembedded-devel mailing list