[RFC] recipes-efl inside meta-oe or meta-efl next to meta-oe?

[RFC] recipes-efl inside meta-oe or meta-efl next to meta-oe?

[Koen Kooi]

Hi,

I'd like to import the EFL recipes Martin did from meta-shr into the meta-openembedded repo. Before I go bothering Martin about it, what would be the best place to put them?

Inside meta-oe:

meta-openembedded/
	meta-oe/
		recipes-efl

or next to it?

meta-openembedded/
	meta-oe/
	meta-efl/

regards,

Koen

Re: [RFC] recipes-efl inside meta-oe or meta-efl next to meta-oe?

[Otavio Salvador]

On Wed, Mar 23, 2011 at 08:49, Koen Kooi <koen@dominion.thruhere.net> wrote:
> Inside meta-oe:
>
> meta-openembedded/
>        meta-oe/
>                recipes-efl

+1

-- 
Otavio Salvador                             O.S. Systems
E-mail: otavio@ossystems.com.br  http://www.ossystems.com.br
Mobile: +55 53 9981-7854              http://projetos.ossystems.com.br

Re: [RFC] recipes-efl inside meta-oe or meta-efl next to meta-oe?

[Richard Purdie]

On Wed, 2011-03-23 at 12:49 +0100, Koen Kooi wrote:
> I'd like to import the EFL recipes Martin did from meta-shr into the meta-openembedded repo. Before I go bothering Martin about it, what would be the best place to put them?
> 
> Inside meta-oe:
> 
> meta-openembedded/
> 	meta-oe/
> 		recipes-efl
> 
> or next to it?
> 
> meta-openembedded/
> 	meta-oe/
> 	meta-efl/

I think the latter might be better in this case. A lot depends on who is
going to maintain them and what the maintainer model is going to be. I
think keeping things we can logically separate from meta-oe separate is
a good thing though in general. We need people to start thinking more in
terms of layers.

Cheers,

Richard

Re: [RFC] recipes-efl inside meta-oe or meta-efl next to meta-oe?

[Graeme Gregory]

On Wed, Mar 23, 2011 at 12:24:59PM +0000, Richard Purdie wrote:
> On Wed, 2011-03-23 at 12:49 +0100, Koen Kooi wrote:
> > I'd like to import the EFL recipes Martin did from meta-shr into the meta-openembedded repo. Before I go bothering Martin about it, what would be the best place to put them?
> > 
> > Inside meta-oe:
> > 
> > meta-openembedded/
> > 	meta-oe/
> > 		recipes-efl
> > 
> > or next to it?
> > 
> > meta-openembedded/
> > 	meta-oe/
> > 	meta-efl/
> 
> I think the latter might be better in this case. A lot depends on who is
> going to maintain them and what the maintainer model is going to be. I
> think keeping things we can logically separate from meta-oe separate is
> a good thing though in general. We need people to start thinking more in
> terms of layers.
> 
I was just about to say all this but Richard obviously types quicker.

Yes I think earlier we start breaking OE into smaller contained chunks
the better.

Graeme

Re: [RFC] recipes-efl inside meta-oe or meta-efl next to meta-oe?

[Khem Raj]

On Wed, Mar 23, 2011 at 4:49 AM, Koen Kooi <koen@dominion.thruhere.net> wrote:
> Hi,
>
> I'd like to import the EFL recipes Martin did from meta-shr into the meta-openembedded repo. Before I go bothering Martin about it, what would be the best place to put them?
>
> Inside meta-oe:
>
> meta-openembedded/
>        meta-oe/
>                recipes-efl

Can efl we layered directly on top of oe-core  ? i.e. without needing meta-oe
in that case its better to be an independent layer. otherwise I would say put
them under recipes-efl

>
> or next to it?
>
> meta-openembedded/
>        meta-oe/
>        meta-efl/
>
> regards,
>
> Koen
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>

Re: [RFC] recipes-efl inside meta-oe or meta-efl next to meta-oe?

[Koen Kooi]

Op 23 mrt 2011, om 16:19 heeft Khem Raj het volgende geschreven:

> On Wed, Mar 23, 2011 at 4:49 AM, Koen Kooi <koen@dominion.thruhere.net> wrote:
>> Hi,
>> 
>> I'd like to import the EFL recipes Martin did from meta-shr into the meta-openembedded repo. Before I go bothering Martin about it, what would be the best place to put them?
>> 
>> Inside meta-oe:
>> 
>> meta-openembedded/
>>        meta-oe/
>>                recipes-efl
> 
> Can efl we layered directly on top of oe-core  ? i.e. without needing meta-oe
> in that case its better to be an independent layer. otherwise I would say put
> them under recipes-efl

I think that's a misleading heuristic, I would like to give people the option to opt-in for extra recipes (parse time, legal sign-off, etc), instead of stuffing 5k recipes into meta-oe.
If the person looking after efl* wants it in meta-oe, so be it, it's the maintainers call.

regards,

Koen

Re: [RFC] recipes-efl inside meta-oe or meta-efl next to meta-oe?

[Koen Kooi]

Op 23 mrt 2011, om 16:33 heeft Martin Jansa het volgende geschreven:

> On Wed, Mar 23, 2011 at 08:19:31AM -0700, Khem Raj wrote:
>> On Wed, Mar 23, 2011 at 4:49 AM, Koen Kooi <koen@dominion.thruhere.net> wrote:
>>> Hi,
>>> 
>>> I'd like to import the EFL recipes Martin did from meta-shr into the meta-openembedded repo. Before I go bothering Martin about it, what would be the best place to put them?
>>> 
>>> Inside meta-oe:
>>> 
>>> meta-openembedded/
>>>        meta-oe/
>>>                recipes-efl
>> 
>> Can efl we layered directly on top of oe-core  ? i.e. without needing meta-oe
>> in that case its better to be an independent layer. otherwise I would say put
>> them under recipes-efl
> 
> Do we want just efl there, or also e-wm, extra modules and apps from e17 dir,
> stuff like illume-image and tasks?
> 
> meta-oe/recipes-efl looks enough for just efl, but then we should add
> something like meta-oe/recipes-e17 and it has also few own bbclasses, so I'm in 
> favor of starting with meta-efl.
> 
> I can try to move it to meta-efl and check how big is dependency-tree of

If you want to build e-wm, you need the following in meta-oe: giflib, mime-support, gnutls, libfribidi and a LIC_FILES_CHKSUM for guile

I currently have the following in meta-efl:

meta-efl/recipes-efl/e17/forecasts_svn.bb
meta-efl/recipes-efl/e17/e-wm_svn.bb
meta-efl/recipes-efl/e17/diskio_svn.bb
meta-efl/recipes-efl/e17/waker
meta-efl/recipes-efl/e17/waker/0001-waker-remove-old-ecore_string_init-and-ecore_string_.patch
meta-efl/recipes-efl/e17/exalt_svn.bb
meta-efl/recipes-efl/e17/efm-nav_svn.bb
meta-efl/recipes-efl/e17/enjoy_svn.bb
meta-efl/recipes-efl/e17/cpu_svn.bb
meta-efl/recipes-efl/e17/expedite_svn.bb
meta-efl/recipes-efl/e17/e-wm
meta-efl/recipes-efl/e17/e-wm/illume-disable-screensaver.patch
meta-efl/recipes-efl/e17/e-wm/illume-flaunch-fix.patch
meta-efl/recipes-efl/e17/e-wm/wizard-module-skipping.patch
meta-efl/recipes-efl/e17/e-wm/applications.menu
meta-efl/recipes-efl/e17/e-wm/enlightenment_start.oe
meta-efl/recipes-efl/e17/exquisite-theme-illume.bb
meta-efl/recipes-efl/e17/emprint_svn.bb
meta-efl/recipes-efl/e17/exquisite_svn.bb
meta-efl/recipes-efl/e17/e-tasks
meta-efl/recipes-efl/e17/e-tasks/depends.eina.patch
meta-efl/recipes-efl/e17/e-tasks/genlist_item_insert_before.api.patch
meta-efl/recipes-efl/e17/efm-pathbar_svn.bb
meta-efl/recipes-efl/e17/uptime_svn.bb
meta-efl/recipes-efl/e17/illume-keyboards-shr
meta-efl/recipes-efl/e17/illume-keyboards-shr/0001-Makefile-update-KEYBOARDS_DIR-for-new-illume2.patch
meta-efl/recipes-efl/e17/e-wm-theme-illume-efenniht_svn.bb
meta-efl/recipes-efl/e17/e-tasks_svn.bb
meta-efl/recipes-efl/e17/eve_svn.bb
meta-efl/recipes-efl/e17/news_svn.bb
meta-efl/recipes-efl/e17/rain_svn.bb
meta-efl/recipes-efl/e17/efm-path_svn.bb
meta-efl/recipes-efl/e17/elementary-alarm_svn.bb
meta-efl/recipes-efl/e17/places_svn.bb
meta-efl/recipes-efl/e17/elmdentica_svn.bb
meta-efl/recipes-efl/e17/elfe_svn.bb
meta-efl/recipes-efl/e17/notification_svn.bb
meta-efl/recipes-efl/e17/exalt-client_svn.bb
meta-efl/recipes-efl/e17/e-module.inc
meta-efl/recipes-efl/e17/rage_svn.bb
meta-efl/recipes-efl/e17/screenshot_svn.bb
meta-efl/recipes-efl/e17/flame_svn.bb
meta-efl/recipes-efl/e17/edje-viewer_svn.bb
meta-efl/recipes-efl/e17/exquisite
meta-efl/recipes-efl/e17/exquisite/exquisite-init
meta-efl/recipes-efl/e17/exquisite/splashfuncs
meta-efl/recipes-efl/e17/waker_svn.bb
meta-efl/recipes-efl/e17/eve
meta-efl/recipes-efl/e17/eve/0001-eve-remove-unconditional-ewk_view_context_menu_forwa.patch
meta-efl/recipes-efl/e17/eve/eve-theme-for-smaller-screens.patch
meta-efl/recipes-efl/e17/illume-keyboards-shr_git.bb
meta-efl/recipes-efl/efl
meta-efl/recipes-efl/efl/azy_svn.bb
meta-efl/recipes-efl/efl/eeze_1.0.0.bb
meta-efl/recipes-efl/efl/efreet
meta-efl/recipes-efl/efl/efreet/changeset_trunk_r57435.patch
meta-efl/recipes-efl/efl/epdf_svn.bb
meta-efl/recipes-efl/efl/engrave_svn.bb
meta-efl/recipes-efl/efl/eet_svn.bb
meta-efl/recipes-efl/efl/elementary_svn.bb
meta-efl/recipes-efl/efl/edje_svn.bb
meta-efl/recipes-efl/efl/ecore_1.0.0.bb
meta-efl/recipes-efl/efl/ecore
meta-efl/recipes-efl/efl/ecore/fix-ecore-fb-initialization.patch
meta-efl/recipes-efl/efl/ecore/exit_uclibc.patch
meta-efl/recipes-efl/efl/edb_svn.bb
meta-efl/recipes-efl/efl/imlib2_svn.bb
meta-efl/recipes-efl/efl/eeze_svn.bb
meta-efl/recipes-efl/efl/e-wm-illume-dict-pl_git.bb
meta-efl/recipes-efl/efl/edje_1.0.0.bb
meta-efl/recipes-efl/efl/embryo_1.0.0.bb
meta-efl/recipes-efl/efl/edbus.inc
meta-efl/recipes-efl/efl/edbus_svn.bb
meta-efl/recipes-efl/efl/libeweather_svn.bb
meta-efl/recipes-efl/efl/edbus_1.0.0.bb
meta-efl/recipes-efl/efl/efreet_svn.bb
meta-efl/recipes-efl/efl/epeg_svn.bb
meta-efl/recipes-efl/efl/eina.inc
meta-efl/recipes-efl/efl/emotion_svn.bb
meta-efl/recipes-efl/efl/libeflvala_svn.bb
meta-efl/recipes-efl/efl/eina_svn.bb
meta-efl/recipes-efl/efl/ecore_svn.bb
meta-efl/recipes-efl/efl/embryo.inc
meta-efl/recipes-efl/efl/embryo_svn.bb
meta-efl/recipes-efl/efl/edje-fpu.inc
meta-efl/recipes-efl/efl/eet_1.4.0.bb
meta-efl/recipes-efl/efl/eeze.inc
meta-efl/recipes-efl/efl/elementary-theme-efenniht_svn.bb
meta-efl/recipes-efl/efl/evas.inc
meta-efl/recipes-efl/efl/ecore.inc
meta-efl/recipes-efl/efl/ethumb_svn.bb
meta-efl/recipes-efl/efl/edje.inc
meta-efl/recipes-efl/efl/efreet_1.0.0.bb
meta-efl/recipes-efl/efl/evas_svn.bb
meta-efl/recipes-efl/tasks
meta-efl/recipes-efl/tasks/task-x11-illume.bb
meta-efl/conf
meta-efl/conf/layer.conf
meta-efl/classes
meta-efl/classes/e.bbclass
meta-efl/classes/e-base.bbclass
meta-efl/classes/vala.bbclass
meta-efl/classes/efl.bbclass

I'll push the meta-oe bits later tonight and leave the meta-efl stuff up to Martin :)

After we sort out the libnl1/nm mess in .dev I'm going to work on meta-gnome.

regards,

Koen

Re: [RFC] recipes-efl inside meta-oe or meta-efl next to meta-oe?

[Richard Purdie]

On Wed, 2011-03-23 at 08:19 -0700, Khem Raj wrote:
> On Wed, Mar 23, 2011 at 4:49 AM, Koen Kooi <koen@dominion.thruhere.net> wrote:
> > Hi,
> >
> > I'd like to import the EFL recipes Martin did from meta-shr into the meta-openembedded repo. Before I go bothering Martin about it, what would be the best place to put them?
> >
> > Inside meta-oe:
> >
> > meta-openembedded/
> >        meta-oe/
> >                recipes-efl
> 
> Can efl we layered directly on top of oe-core  ? i.e. without needing meta-oe
> in that case its better to be an independent layer. otherwise I would say put
> them under recipes-efl

I'd hope that it would be possible to run it on top of oe-core, at least
for its basic components. If its not possible, I'd like to understand
why so we can see if its possible to fix it.

Ultimately, we need to add some kind of layer dependency information
although we don't have an implementation of that yet.

Cheers,

Richard

Re: [RFC] recipes-efl inside meta-oe or meta-efl next to meta-oe?

[Graeme Gregory]

On Wed, Mar 23, 2011 at 08:19:31AM -0700, Khem Raj wrote:
> On Wed, Mar 23, 2011 at 4:49 AM, Koen Kooi <koen@dominion.thruhere.net> wrote:
> > Hi,
> >
> > I'd like to import the EFL recipes Martin did from meta-shr into the meta-openembedded repo. Before I go bothering Martin about it, what would be the best place to put them?
> >
> > Inside meta-oe:
> >
> > meta-openembedded/
> >        meta-oe/
> >                recipes-efl
> 
> Can efl we layered directly on top of oe-core  ? i.e. without needing meta-oe
> in that case its better to be an independent layer. otherwise I would say put
> them under recipes-efl
> 
That is certainly not how I see layers being built up. I am expecting
in future us to have things like.

meta-gnome
meta-kde
meta-efl
meta-lxde
meta-xorg

Obviosuly none of these is an independant layer of its own, and to make a
complete system you will require a stack of layers with the appropriate
recipes. This really is where the DISTROs come in as they select the layer
mix they want.

Graeme

Re: [RFC] recipes-efl inside meta-oe or meta-efl next to meta-oe?

[Koen Kooi]

Op 23 mrt 2011, om 16:39 heeft Richard Purdie het volgende geschreven:

> On Wed, 2011-03-23 at 08:19 -0700, Khem Raj wrote:
>> On Wed, Mar 23, 2011 at 4:49 AM, Koen Kooi <koen@dominion.thruhere.net> wrote:
>>> Hi,
>>> 
>>> I'd like to import the EFL recipes Martin did from meta-shr into the meta-openembedded repo. Before I go bothering Martin about it, what would be the best place to put them?
>>> 
>>> Inside meta-oe:
>>> 
>>> meta-openembedded/
>>>       meta-oe/
>>>               recipes-efl
>> 
>> Can efl we layered directly on top of oe-core  ? i.e. without needing meta-oe
>> in that case its better to be an independent layer. otherwise I would say put
>> them under recipes-efl
> 
> I'd hope that it would be possible to run it on top of oe-core, at least
> for its basic components. If its not possible, I'd like to understand
> why so we can see if its possible to fix it.
> 
> Ultimately, we need to add some kind of layer dependency information
> although we don't have an implementation of that yet.

I;m currently usng a low-tech README for that:

http://gitorious.org/angstrom/angstrom-layers/blobs/master/README

would be nice to come up with something machine parse-able.

regards,

Koen

Re: [RFC] recipes-efl inside meta-oe or meta-efl next to meta-oe?

[Joshua Lock]

On Wed, 2011-03-23 at 15:40 +0000, Graeme Gregory wrote:
> On Wed, Mar 23, 2011 at 08:19:31AM -0700, Khem Raj wrote:
> > On Wed, Mar 23, 2011 at 4:49 AM, Koen Kooi <koen@dominion.thruhere.net> wrote:
> > > Hi,
> > >
> > > I'd like to import the EFL recipes Martin did from meta-shr into the meta-openembedded repo. Before I go bothering Martin about it, what would be the best place to put them?
> > >
> > > Inside meta-oe:
> > >
> > > meta-openembedded/
> > >        meta-oe/
> > >                recipes-efl
> > 
> > Can efl we layered directly on top of oe-core  ? i.e. without needing meta-oe
> > in that case its better to be an independent layer. otherwise I would say put
> > them under recipes-efl
> > 
> That is certainly not how I see layers being built up. I am expecting
> in future us to have things like.
> 
> meta-gnome
> meta-kde
> meta-efl
> meta-lxde
> meta-xorg

Me too, in fact I think this image from the Yocto Project website
succinctly portrays the goal:
http://www.yoctoproject.org/sites/default/files/yocto-layers_1.png

Possibly less the meta-yocto but you get the point.

Cheers,
Joshua
-- 
Joshua Lock
        Yocto Build System Monkey
        Intel Open Source Technology Centre

Re: [RFC] recipes-efl inside meta-oe or meta-efl next to meta-oe?

[Richard Purdie]

On Wed, 2011-03-23 at 16:42 +0100, Koen Kooi wrote:
> Op 23 mrt 2011, om 16:39 heeft Richard Purdie het volgende geschreven:
> 
> > On Wed, 2011-03-23 at 08:19 -0700, Khem Raj wrote:
> >> On Wed, Mar 23, 2011 at 4:49 AM, Koen Kooi <koen@dominion.thruhere.net> wrote:
> >>> Hi,
> >>> 
> >>> I'd like to import the EFL recipes Martin did from meta-shr into the meta-openembedded repo. Before I go bothering Martin about it, what would be the best place to put them?
> >>> 
> >>> Inside meta-oe:
> >>> 
> >>> meta-openembedded/
> >>>       meta-oe/
> >>>               recipes-efl
> >> 
> >> Can efl we layered directly on top of oe-core  ? i.e. without needing meta-oe
> >> in that case its better to be an independent layer. otherwise I would say put
> >> them under recipes-efl
> > 
> > I'd hope that it would be possible to run it on top of oe-core, at least
> > for its basic components. If its not possible, I'd like to understand
> > why so we can see if its possible to fix it.
> > 
> > Ultimately, we need to add some kind of layer dependency information
> > although we don't have an implementation of that yet.
> 
> I;m currently usng a low-tech README for that:
> 
> http://gitorious.org/angstrom/angstrom-layers/blobs/master/README
> 
> would be nice to come up with something machine parse-able.

That's the plan, have something in README's for now and then improve the
infrastructure over time to automate it.

We could define a simple convention of something like this in
layer.conf:

LAYERNAMES += "thislayername:<optionalversion>"

LAYERREQUIRES := '${@oe.util.layerrequirements(["layerA:versionA", "layerb:versionB"])}'

but its just random ideas off the top of my head at the moment!

Cheers,

Richard

Re: [RFC] recipes-efl inside meta-oe or meta-efl next to meta-oe?

[Richard Purdie]

On Wed, 2011-03-23 at 15:40 +0000, Graeme Gregory wrote:
> On Wed, Mar 23, 2011 at 08:19:31AM -0700, Khem Raj wrote:
> > On Wed, Mar 23, 2011 at 4:49 AM, Koen Kooi <koen@dominion.thruhere.net> wrote:
> > > Hi,
> > >
> > > I'd like to import the EFL recipes Martin did from meta-shr into the meta-openembedded repo. Before I go bothering Martin about it, what would be the best place to put them?
> > >
> > > Inside meta-oe:
> > >
> > > meta-openembedded/
> > >        meta-oe/
> > >                recipes-efl
> > 
> > Can efl we layered directly on top of oe-core  ? i.e. without needing meta-oe
> > in that case its better to be an independent layer. otherwise I would say put
> > them under recipes-efl
> > 
> That is certainly not how I see layers being built up. I am expecting
> in future us to have things like.
> 
> meta-gnome
> meta-kde
> meta-efl
> meta-lxde
> meta-xorg
> 
> Obviosuly none of these is an independant layer of its own, and to make a
> complete system you will require a stack of layers with the appropriate
> recipes. This really is where the DISTROs come in as they select the layer
> mix they want.

I don't disagree, I would be interested to explore what would be missing
from oe-core to enable some of these to work though. If it is just one
or two packages it would raise some interesting questions.

Certainly having a requirement of depending on meta-oe might not be
necessary in all cases.

Cheers,

Richard

Re: [RFC] recipes-efl inside meta-oe or meta-efl next to meta-oe?

[Graeme Gregory]

On Wed, Mar 23, 2011 at 04:03:04PM +0000, Joshua Lock wrote:
> On Wed, 2011-03-23 at 15:40 +0000, Graeme Gregory wrote:
> > On Wed, Mar 23, 2011 at 08:19:31AM -0700, Khem Raj wrote:
> > > On Wed, Mar 23, 2011 at 4:49 AM, Koen Kooi <koen@dominion.thruhere.net> wrote:
> > > > Hi,
> > > >
> > > > I'd like to import the EFL recipes Martin did from meta-shr into the meta-openembedded repo. Before I go bothering Martin about it, what would be the best place to put them?
> > > >
> > > > Inside meta-oe:
> > > >
> > > > meta-openembedded/
> > > >        meta-oe/
> > > >                recipes-efl
> > > 
> > > Can efl we layered directly on top of oe-core  ? i.e. without needing meta-oe
> > > in that case its better to be an independent layer. otherwise I would say put
> > > them under recipes-efl
> > > 
> > That is certainly not how I see layers being built up. I am expecting
> > in future us to have things like.
> > 
> > meta-gnome
> > meta-kde
> > meta-efl
> > meta-lxde
> > meta-xorg
> 
> Me too, in fact I think this image from the Yocto Project website
> succinctly portrays the goal:
> http://www.yoctoproject.org/sites/default/files/yocto-layers_1.png
> 
> Possibly less the meta-yocto but you get the point.
> 
I hope not as thats a truly horrible diagram.

I dont think there is anyway in modern linux to produce a nice neat stack
like that. Once you move beyond trivial images.

Graeme

Re: [RFC] recipes-efl inside meta-oe or meta-efl next to meta-oe?

[Koen Kooi]

Op 23 mrt 2011, om 17:46 heeft Martin Jansa het volgende geschreven:
>> Feel free to push this meta-efl to and I can continue from it.

Done! It needs a lot of LIC_FILE_CHKSUMS, though, be warned.

Re: [RFC] recipes-efl inside meta-oe or meta-efl next to meta-oe?

[Richard Purdie]

On Wed, 2011-03-23 at 17:52 +0000, Graeme Gregory wrote:
> On Wed, Mar 23, 2011 at 04:03:04PM +0000, Joshua Lock wrote:
> > On Wed, 2011-03-23 at 15:40 +0000, Graeme Gregory wrote:
> > > On Wed, Mar 23, 2011 at 08:19:31AM -0700, Khem Raj wrote:
> > > > On Wed, Mar 23, 2011 at 4:49 AM, Koen Kooi <koen@dominion.thruhere.net> wrote:
> > > > > Hi,
> > > > >
> > > > > I'd like to import the EFL recipes Martin did from meta-shr into the meta-openembedded repo. Before I go bothering Martin about it, what would be the best place to put them?
> > > > >
> > > > > Inside meta-oe:
> > > > >
> > > > > meta-openembedded/
> > > > >        meta-oe/
> > > > >                recipes-efl
> > > > 
> > > > Can efl we layered directly on top of oe-core  ? i.e. without needing meta-oe
> > > > in that case its better to be an independent layer. otherwise I would say put
> > > > them under recipes-efl
> > > > 
> > > That is certainly not how I see layers being built up. I am expecting
> > > in future us to have things like.
> > > 
> > > meta-gnome
> > > meta-kde
> > > meta-efl
> > > meta-lxde
> > > meta-xorg
> > 
> > Me too, in fact I think this image from the Yocto Project website
> > succinctly portrays the goal:
> > http://www.yoctoproject.org/sites/default/files/yocto-layers_1.png
> > 
> > Possibly less the meta-yocto but you get the point.
> > 
> I hope not as thats a truly horrible diagram.
> 
> I dont think there is anyway in modern linux to produce a nice neat stack
> like that. Once you move beyond trivial images.

The diagram is idealised but I think the concepts there are valid, for
example, bring in the meta-linaro layer to use the linaro toolchain,
bring in a BSP layer for a particular piece of hardware support and so
forth. Certainly, a developer is likely to have local tweaks in a layer
of their own on top.

Why wouldn't that work?

Cheers,

Richard

Re: [RFC] recipes-efl inside meta-oe or meta-efl next to meta-oe?

[Graeme Gregory]

On Wed, Mar 23, 2011 at 11:02:17PM +0000, Richard Purdie wrote:
> On Wed, 2011-03-23 at 17:52 +0000, Graeme Gregory wrote:
> > On Wed, Mar 23, 2011 at 04:03:04PM +0000, Joshua Lock wrote:
> > > On Wed, 2011-03-23 at 15:40 +0000, Graeme Gregory wrote:
> > > > On Wed, Mar 23, 2011 at 08:19:31AM -0700, Khem Raj wrote:
> > > > > On Wed, Mar 23, 2011 at 4:49 AM, Koen Kooi <koen@dominion.thruhere.net> wrote:
> > > > > > Hi,
> > > > > >
> > > > > > I'd like to import the EFL recipes Martin did from meta-shr into the meta-openembedded repo. Before I go bothering Martin about it, what would be the best place to put them?
> > > > > >
> > > > > > Inside meta-oe:
> > > > > >
> > > > > > meta-openembedded/
> > > > > >        meta-oe/
> > > > > >                recipes-efl
> > > > > 
> > > > > Can efl we layered directly on top of oe-core  ? i.e. without needing meta-oe
> > > > > in that case its better to be an independent layer. otherwise I would say put
> > > > > them under recipes-efl
> > > > > 
> > > > That is certainly not how I see layers being built up. I am expecting
> > > > in future us to have things like.
> > > > 
> > > > meta-gnome
> > > > meta-kde
> > > > meta-efl
> > > > meta-lxde
> > > > meta-xorg
> > > 
> > > Me too, in fact I think this image from the Yocto Project website
> > > succinctly portrays the goal:
> > > http://www.yoctoproject.org/sites/default/files/yocto-layers_1.png
> > > 
> > > Possibly less the meta-yocto but you get the point.
> > > 
> > I hope not as thats a truly horrible diagram.
> > 
> > I dont think there is anyway in modern linux to produce a nice neat stack
> > like that. Once you move beyond trivial images.
> 
> The diagram is idealised but I think the concepts there are valid, for
> example, bring in the meta-linaro layer to use the linaro toolchain,
> bring in a BSP layer for a particular piece of hardware support and so
> forth. Certainly, a developer is likely to have local tweaks in a layer
> of their own on top.
> 
> Why wouldn't that work?
> 
The diagram demonstrates a nice stack, but what about if you want two
gui layers. Real life example, gnome and kde have cross dependencies on
each other.

In a real system you just cant pile up a nice little stack of components. It
works more like lego where you have multiple components that fit together
depending on multiple components to hold them up.

The diagram is overly idealised to the point of zero information, fit for
marketing but not engineering.

Graeme

Re: [RFC] recipes-efl inside meta-oe or meta-efl next to meta-oe?

[Philip Balister]

On 03/23/2011 07:53 PM, Graeme Gregory wrote:
> On Wed, Mar 23, 2011 at 11:02:17PM +0000, Richard Purdie wrote:
>> On Wed, 2011-03-23 at 17:52 +0000, Graeme Gregory wrote:
>>> On Wed, Mar 23, 2011 at 04:03:04PM +0000, Joshua Lock wrote:
>>>> On Wed, 2011-03-23 at 15:40 +0000, Graeme Gregory wrote:
>>>>> On Wed, Mar 23, 2011 at 08:19:31AM -0700, Khem Raj wrote:
>>>>>> On Wed, Mar 23, 2011 at 4:49 AM, Koen Kooi<koen@dominion.thruhere.net>  wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> I'd like to import the EFL recipes Martin did from meta-shr into the meta-openembedded repo. Before I go bothering Martin about it, what would be the best place to put them?
>>>>>>>
>>>>>>> Inside meta-oe:
>>>>>>>
>>>>>>> meta-openembedded/
>>>>>>>         meta-oe/
>>>>>>>                 recipes-efl
>>>>>>
>>>>>> Can efl we layered directly on top of oe-core  ? i.e. without needing meta-oe
>>>>>> in that case its better to be an independent layer. otherwise I would say put
>>>>>> them under recipes-efl
>>>>>>
>>>>> That is certainly not how I see layers being built up. I am expecting
>>>>> in future us to have things like.
>>>>>
>>>>> meta-gnome
>>>>> meta-kde
>>>>> meta-efl
>>>>> meta-lxde
>>>>> meta-xorg
>>>>
>>>> Me too, in fact I think this image from the Yocto Project website
>>>> succinctly portrays the goal:
>>>> http://www.yoctoproject.org/sites/default/files/yocto-layers_1.png
>>>>
>>>> Possibly less the meta-yocto but you get the point.
>>>>
>>> I hope not as thats a truly horrible diagram.
>>>
>>> I dont think there is anyway in modern linux to produce a nice neat stack
>>> like that. Once you move beyond trivial images.
>>
>> The diagram is idealised but I think the concepts there are valid, for
>> example, bring in the meta-linaro layer to use the linaro toolchain,
>> bring in a BSP layer for a particular piece of hardware support and so
>> forth. Certainly, a developer is likely to have local tweaks in a layer
>> of their own on top.
>>
>> Why wouldn't that work?
>>
> The diagram demonstrates a nice stack, but what about if you want two
> gui layers. Real life example, gnome and kde have cross dependencies on
> each other.
>
> In a real system you just cant pile up a nice little stack of components. It
> works more like lego where you have multiple components that fit together
> depending on multiple components to hold them up.
>
> The diagram is overly idealised to the point of zero information, fit for
> marketing but not engineering.

At the risk of being blunt, anytime I see a figure that looks that neat, 
my bs detector goes off.

Graeme managed to say that much better than I did.

Philip

Re: [RFC] recipes-efl inside meta-oe or meta-efl next to meta-oe?

[Richard Purdie]

On Wed, 2011-03-23 at 19:57 -0400, Philip Balister wrote:
> On 03/23/2011 07:53 PM, Graeme Gregory wrote:
> > On Wed, Mar 23, 2011 at 11:02:17PM +0000, Richard Purdie wrote:
> >> On Wed, 2011-03-23 at 17:52 +0000, Graeme Gregory wrote:
> >>> On Wed, Mar 23, 2011 at 04:03:04PM +0000, Joshua Lock wrote:
> >>>> On Wed, 2011-03-23 at 15:40 +0000, Graeme Gregory wrote:
> >>>> Me too, in fact I think this image from the Yocto Project website
> >>>> succinctly portrays the goal:
> >>>> http://www.yoctoproject.org/sites/default/files/yocto-layers_1.png
> >>>>
> >>>> Possibly less the meta-yocto but you get the point.
> >>>>
> >>> I hope not as thats a truly horrible diagram.
> >>>
> >>> I dont think there is anyway in modern linux to produce a nice neat stack
> >>> like that. Once you move beyond trivial images.
> >>
> >> The diagram is idealised but I think the concepts there are valid, for
> >> example, bring in the meta-linaro layer to use the linaro toolchain,
> >> bring in a BSP layer for a particular piece of hardware support and so
> >> forth. Certainly, a developer is likely to have local tweaks in a layer
> >> of their own on top.
> >>
> >> Why wouldn't that work?
> >>
> > The diagram demonstrates a nice stack, but what about if you want two
> > gui layers. Real life example, gnome and kde have cross dependencies on
> > each other.
> >
> > In a real system you just cant pile up a nice little stack of components. It
> > works more like lego where you have multiple components that fit together
> > depending on multiple components to hold them up.
> >
> > The diagram is overly idealised to the point of zero information, fit for
> > marketing but not engineering.
> 
> At the risk of being blunt, anytime I see a figure that looks that neat, 
> my bs detector goes off.
> 
> Graeme managed to say that much better than I did.

What do you want as a reply here?

a) Lets delete the diagram now, it obviously doesn't cover corner case 
   781.
b) Mark the diagram "FOR MARKETING USE ONLY!"
c) Give up on explaining any of OE to anyone who isn't a highly focused 
   embedded engineer. Its impossible to understand any concept unless 
   you understand all the engineering details.

Have either of you ever tried to explain some of the concepts we're
dealing with to people who aren't deeply engaged engineers?

Having a model showing the kinds of things layers can do is extremely
helpful in explaining the concept to people.

Part of OE's problem and the number one complaint about it is that its
hard to understand. If as I/others try and put things into terms that
others can understand get undermined with this kind of response its just
going to further the impression that OE is nice but never going to be
useful in the real world.

As for whether that diagram is practical, I actually believe it is in
some cases, like the one I described above. Certainly not all but its
worth trying to strive to simplify and make things fit simpler models
if/when we can. If we don't even bother trying, there is no chance
things will improve.

Cheers,

Richard

Re: [RFC] recipes-efl inside meta-oe or meta-efl next to meta-oe?

[Khem Raj]

On (23/03/11 23:53), Graeme Gregory wrote:
> On Wed, Mar 23, 2011 at 11:02:17PM +0000, Richard Purdie wrote:
> > On Wed, 2011-03-23 at 17:52 +0000, Graeme Gregory wrote:
> > > On Wed, Mar 23, 2011 at 04:03:04PM +0000, Joshua Lock wrote:
> > > > On Wed, 2011-03-23 at 15:40 +0000, Graeme Gregory wrote:
> > > > > On Wed, Mar 23, 2011 at 08:19:31AM -0700, Khem Raj wrote:
> > > > > > On Wed, Mar 23, 2011 at 4:49 AM, Koen Kooi <koen@dominion.thruhere.net> wrote:
> > > > > > > Hi,
> > > > > > >
> > > > > > > I'd like to import the EFL recipes Martin did from meta-shr into the meta-openembedded repo. Before I go bothering Martin about it, what would be the best place to put them?
> > > > > > >
> > > > > > > Inside meta-oe:
> > > > > > >
> > > > > > > meta-openembedded/
> > > > > > >        meta-oe/
> > > > > > >                recipes-efl
> > > > > > 
> > > > > > Can efl we layered directly on top of oe-core  ? i.e. without needing meta-oe
> > > > > > in that case its better to be an independent layer. otherwise I would say put
> > > > > > them under recipes-efl
> > > > > > 
> > > > > That is certainly not how I see layers being built up. I am expecting
> > > > > in future us to have things like.
> > > > > 
> > > > > meta-gnome
> > > > > meta-kde
> > > > > meta-efl
> > > > > meta-lxde
> > > > > meta-xorg
> > > > 
> > > > Me too, in fact I think this image from the Yocto Project website
> > > > succinctly portrays the goal:
> > > > http://www.yoctoproject.org/sites/default/files/yocto-layers_1.png
> > > > 
> > > > Possibly less the meta-yocto but you get the point.
> > > > 
> > > I hope not as thats a truly horrible diagram.
> > > 
> > > I dont think there is anyway in modern linux to produce a nice neat stack
> > > like that. Once you move beyond trivial images.
> > 
> > The diagram is idealised but I think the concepts there are valid, for
> > example, bring in the meta-linaro layer to use the linaro toolchain,
> > bring in a BSP layer for a particular piece of hardware support and so
> > forth. Certainly, a developer is likely to have local tweaks in a layer
> > of their own on top.
> > 
> > Why wouldn't that work?
> > 
> The diagram demonstrates a nice stack, but what about if you want two
> gui layers. Real life example, gnome and kde have cross dependencies on
> each other.
> 
> In a real system you just cant pile up a nice little stack of components. It
> works more like lego where you have multiple components that fit together
> depending on multiple components to hold them up.

from 36000ft then we could have three layers
kde, gnome, and kde-gnome-common and it would still comply to the
diagram in general

> 
> The diagram is overly idealised to the point of zero information, fit for
> marketing but not engineering.
> 
> Graeme
> 
> 
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

-- 
-Khem

Re: [RFC] recipes-efl inside meta-oe or meta-efl next to meta-oe?

[Khem Raj]

On (23/03/11 16:33), Koen Kooi wrote:
> 
> Op 23 mrt 2011, om 16:19 heeft Khem Raj het volgende geschreven:
> 
> > On Wed, Mar 23, 2011 at 4:49 AM, Koen Kooi <koen@dominion.thruhere.net> wrote:
> >> Hi,
> >> 
> >> I'd like to import the EFL recipes Martin did from meta-shr into the meta-openembedded repo. Before I go bothering Martin about it, what would be the best place to put them?
> >> 
> >> Inside meta-oe:
> >> 
> >> meta-openembedded/
> >>        meta-oe/
> >>                recipes-efl
> > 
> > Can efl we layered directly on top of oe-core  ? i.e. without needing meta-oe
> > in that case its better to be an independent layer. otherwise I would say put
> > them under recipes-efl
> 
> I think that's a misleading heuristic, I would like to give people the option to opt-in for extra recipes (parse time, legal sign-off, etc), instead of stuffing 5k recipes into meta-oe.
> If the person looking after efl* wants it in meta-oe, so be it, it's the maintainers call.

Obviously I was thinking of plug and play layers but that may not work
always in practice

> 
> regards,
> 
> Koen

-- 
-Khem

Re: [RFC] recipes-efl inside meta-oe or meta-efl next to meta-oe?

[Graeme Gregory]

On Thu, Mar 24, 2011 at 12:27:28AM +0000, Richard Purdie wrote:
> Have either of you ever tried to explain some of the concepts we're
> dealing with to people who aren't deeply engaged engineers?
> 
Yes, everytime I apply for a new job/contract getting quite used to
explaining it.

> Having a model showing the kinds of things layers can do is extremely
> helpful in explaining the concept to people.
> 
> Part of OE's problem and the number one complaint about it is that its
> hard to understand. If as I/others try and put things into terms that
> others can understand get undermined with this kind of response its just
> going to further the impression that OE is nice but never going to be
> useful in the real world.
> 
> As for whether that diagram is practical, I actually believe it is in
> some cases, like the one I described above. Certainly not all but its
> worth trying to strive to simplify and make things fit simpler models
> if/when we can. If we don't even bother trying, there is no chance
> things will improve.
> 

You miss my point, Joshua's email reads to me like "our goal is to make OE
like this diagram" which if true would cripple OE to being incredibly simple
and non flexible.

My vision of a seperated out OE is to seperate components out into logical
boxes. Ie the gnome box, the kde box, the xorg box. Then like we used to do
with our lego or mecheno sets. When we want to build something we know what
components we want so we select the boxes that contain those components.

Graeme

Re: [RFC] recipes-efl inside meta-oe or meta-efl next to meta-oe?

[Koen Kooi]

Op 24 mrt 2011, om 08:49 heeft Graeme Gregory het volgende geschreven:

> On Thu, Mar 24, 2011 at 12:27:28AM +0000, Richard Purdie wrote:
>> Have either of you ever tried to explain some of the concepts we're
>> dealing with to people who aren't deeply engaged engineers?
>> 
> Yes, everytime I apply for a new job/contract getting quite used to
> explaining it.
> 
>> Having a model showing the kinds of things layers can do is extremely
>> helpful in explaining the concept to people.
>> 
>> Part of OE's problem and the number one complaint about it is that its
>> hard to understand. If as I/others try and put things into terms that
>> others can understand get undermined with this kind of response its just
>> going to further the impression that OE is nice but never going to be
>> useful in the real world.
>> 
>> As for whether that diagram is practical, I actually believe it is in
>> some cases, like the one I described above. Certainly not all but its
>> worth trying to strive to simplify and make things fit simpler models
>> if/when we can. If we don't even bother trying, there is no chance
>> things will improve.
>> 
> 
> You miss my point, Joshua's email reads to me like "our goal is to make OE
> like this diagram" which if true would cripple OE to being incredibly simple
> and non flexible.
> 
> My vision of a seperated out OE is to seperate components out into logical
> boxes. Ie the gnome box, the kde box, the xorg box. Then like we used to do
> with our lego or mecheno sets. When we want to build something we know what
> components we want so we select the boxes that contain those components.

What I would like is to have a tool that can parse the READMEs and generate:

digraph depends {
    node [shape=plaintext]
meta_oe -> openembedded_core
meta_efl -> openembedded_core
meta_efl -> meta_oe
meta_angstrom -> openembedded_core
meta_angstrom -> meta_oe
angstrom_layers -> meta_angstrom
angstrom_layers -> meta_oe
angstrom_layers -> openembedded_core
}

Sample output:

http://dominion.thruhere.net/koen/angstrom/layers.png

That for the layers I currently have configured

regards,

Koen

Re: [RFC] recipes-efl inside meta-oe or meta-efl next to meta-oe?

[Graeme Gregory]

On Thu, Mar 24, 2011 at 07:49:27AM +0000, Graeme Gregory wrote:
> On Thu, Mar 24, 2011 at 12:27:28AM +0000, Richard Purdie wrote:
> > Have either of you ever tried to explain some of the concepts we're
> > dealing with to people who aren't deeply engaged engineers?
> > 
> Yes, everytime I apply for a new job/contract getting quite used to
> explaining it.
> 
> > Having a model showing the kinds of things layers can do is extremely
> > helpful in explaining the concept to people.
> > 
> > Part of OE's problem and the number one complaint about it is that its
> > hard to understand. If as I/others try and put things into terms that
> > others can understand get undermined with this kind of response its just
> > going to further the impression that OE is nice but never going to be
> > useful in the real world.
> > 
> > As for whether that diagram is practical, I actually believe it is in
> > some cases, like the one I described above. Certainly not all but its
> > worth trying to strive to simplify and make things fit simpler models
> > if/when we can. If we don't even bother trying, there is no chance
> > things will improve.
> > 
> 
> You miss my point, Joshua's email reads to me like "our goal is to make OE
> like this diagram" which if true would cripple OE to being incredibly simple
> and non flexible.
> 
> My vision of a seperated out OE is to seperate components out into logical
> boxes. Ie the gnome box, the kde box, the xorg box. Then like we used to do
> with our lego or mecheno sets. When we want to build something we know what
> components we want so we select the boxes that contain those components.
> 
And following up from this the diagram is one possible outcome of the
model I am trying to describe in a very poor manner.

Graeme

Re: [RFC] recipes-efl inside meta-oe or meta-efl next to meta-oe?

[Joshua Lock]

On Thu, 2011-03-24 at 07:49 +0000, Graeme Gregory wrote:
> On Thu, Mar 24, 2011 at 12:27:28AM +0000, Richard Purdie wrote:
> > Have either of you ever tried to explain some of the concepts we're
> > dealing with to people who aren't deeply engaged engineers?
> > 
> Yes, everytime I apply for a new job/contract getting quite used to
> explaining it.
> 
> > Having a model showing the kinds of things layers can do is extremely
> > helpful in explaining the concept to people.
> > 
> > Part of OE's problem and the number one complaint about it is that its
> > hard to understand. If as I/others try and put things into terms that
> > others can understand get undermined with this kind of response its just
> > going to further the impression that OE is nice but never going to be
> > useful in the real world.
> > 
> > As for whether that diagram is practical, I actually believe it is in
> > some cases, like the one I described above. Certainly not all but its
> > worth trying to strive to simplify and make things fit simpler models
> > if/when we can. If we don't even bother trying, there is no chance
> > things will improve.
> > 
> 
> You miss my point, Joshua's email reads to me like "our goal is to make OE
> like this diagram" which if true would cripple OE to being incredibly simple
> and non flexible.

It certainly wasn't my intention to imply that, in fact the "me too"
strongly indicates that I agreed with you and that I personally thought
the diagram was a useful *aide* in explaining layers.

> 
> My vision of a seperated out OE is to seperate components out into logical
> boxes. Ie the gnome box, the kde box, the xorg box. Then like we used to do
> with our lego or mecheno sets. When we want to build something we know what
> components we want so we select the boxes that contain those components.

FWIW, this is the same vision I was already agreeing with.

Regards,
Joshua
-- 
Joshua Lock
        Yocto Build System Monkey
        Intel Open Source Technology Centre

Re: [RFC] recipes-efl inside meta-oe or meta-efl next to meta-oe?

[Richard Purdie]

On Thu, 2011-03-24 at 10:26 +0000, Graeme Gregory wrote:
> On Thu, Mar 24, 2011 at 07:49:27AM +0000, Graeme Gregory wrote:
> > On Thu, Mar 24, 2011 at 12:27:28AM +0000, Richard Purdie wrote:
> > > Have either of you ever tried to explain some of the concepts we're
> > > dealing with to people who aren't deeply engaged engineers?
> > > 
> > Yes, everytime I apply for a new job/contract getting quite used to
> > explaining it.
> > 
> > > Having a model showing the kinds of things layers can do is extremely
> > > helpful in explaining the concept to people.
> > > 
> > > Part of OE's problem and the number one complaint about it is that its
> > > hard to understand. If as I/others try and put things into terms that
> > > others can understand get undermined with this kind of response its just
> > > going to further the impression that OE is nice but never going to be
> > > useful in the real world.
> > > 
> > > As for whether that diagram is practical, I actually believe it is in
> > > some cases, like the one I described above. Certainly not all but its
> > > worth trying to strive to simplify and make things fit simpler models
> > > if/when we can. If we don't even bother trying, there is no chance
> > > things will improve.
> > > 
> > 
> > You miss my point, Joshua's email reads to me like "our goal is to make OE
> > like this diagram" which if true would cripple OE to being incredibly simple
> > and non flexible.
> > 
> > My vision of a seperated out OE is to seperate components out into logical
> > boxes. Ie the gnome box, the kde box, the xorg box. Then like we used to do
> > with our lego or mecheno sets. When we want to build something we know what
> > components we want so we select the boxes that contain those components.
> > 
> And following up from this the diagram is one possible outcome of the
> model I am trying to describe in a very poor manner.

Joshua can correct me if I'm wrong but I think his intent in posting it
was to point out that we are trying to split things into building
blocks. Different people visualise things in different ways but the
stack picture shows a possible way you could build some blocks and an
example of the size and shape some of the blocks could take.

Nobody is saying we must have those blocks, only those block and they
must be put together in a particular way. Its just an example which
helps people understand why blocks could be useful, how you might use
them and give people some ideas.

I'd never want to cripple OE or make it non-flexible and neither would
anyone on the Yocto team. The whole point of basing a lot of what we're
doing around OE was due to its flexibility!

Cheers,

Richard