On Fri, Sep 02, 2011 at 01:01:44PM +0200, Koen Kooi wrote:
> Hi,
>
> This has come up in the past, but no one has had time to site down and write
> a proposal yet.
>
> Problem description: The OE-core layer has both too much in it and not enough.
>
> Currently OE-core is basically a relabeling of the poky fork of OE. Due to
> that heritage is has bits in it that aren't considered 'core', but serve as a
> testbed for the proper core metadata. The prime example of this is the sato
> suite. To address this we will need to come up with guidelines what goes into
> OE-core and what people expect to get out of it. Here's a start:
>
> Highlevel goals:
>
> 1) Have a high quality set of "core" metadata
> 2) OE-core needs to be useful on its own
> 3) OE-core needs to be testable on its own
>
> Concrete rootfs goals:
>
> a) be able to build for the 4 blessed architectures: arm, mips,
> powerpc, x86
> b) have multilib support
> c) be able to build a rootfs that has:
> o package management (rpm/deb/opkg)
> o networking support (ifupdown/connman/dnsmasq)
> o have remote access (dropbear/openssh)
> o have user management (shadow/pam)
>
> I think it's safe to say that we all agree on that minimum set of goals. The
> tricky thing is where to put multimedia and GUI stuff. Qt and GTK are
> important enough to get put in core, but where do we draw the line? Where do
> we stop splitting things in recipes-* and start splitting them into layers
> and should those layers live in seperate repositories?
>
> My list of non-BSP, non-distro layers is:
>
> BBLAYERS = " \
> ${TOPDIR}/sources/meta-openembedded/meta-oe \
> ${TOPDIR}/sources/meta-openembedded/meta-efl \
> ${TOPDIR}/sources/meta-openembedded/meta-gpe \
> ${TOPDIR}/sources/meta-openembedded/meta-gnome \
> ${TOPDIR}/sources/meta-openembedded/meta-xfce \
> ${TOPDIR}/sources/openembedded-core/meta \
> "
>
> The gpe, gnome and xfce layers need things like glib-2.0 and gtk, but there's
> a larger overlay between the 3, so gpe and xfce end up depending on the gnome
> layer. Meta-oe is the place where people put things they don't want to
> maintain in a seperate layer, which isn't going to scale longterm.
>
> My not-so-fully-formed idea is:
>
> core - implements above goals
> x11 - base xorg libs, headers, apps. Has bbappends for core recipes to add
> x11 support via DISTRO_FEATURES
> gtk - base gtk things, libs, themes, icons, modules
> qt - base qt things + qwt
>
> efl - depends on core,x11
> gnome - depends on core,x11,gtk
> gpe - depends on core,x11,gtk
> opie - depends on core,qt
> sato - depends on core,x11,gtk
> xfce - depends on core,x11,gtk, gnome
>
> and finally:
>
> oe - leftovers
>
> With this layer structure as starting point can we start a discussion on how
> people would like to set it split? I'd like to leave the question of which
> layer goes into what repository for later.I like this proposal. The point of being able to test oe-core also with graphics (sato) is right, but to test that oe-core is usable in oe-core/x11/gtk/sato layer stack is IMHO even more important as many people are using oe-core just as one of the layers. I've started to merge and upgrade x11 recipes from meta-oe to oe-core (to be able to create x11 layer from it, if we decide so). http://git.openembedded.org/cgit.cgi/openembedded-core-contrib/log/?h=jansa/x11 http://git.openembedded.org/cgit.cgi/meta-openembedded-contrib/log/?h=jansa/x11 http://git.shr-project.org/git/?p=meta-smartphone.git;a=shortlog;h=refs/heads/x11 Regards, -- Martin 'JaMa' Jansa jabber: [email protected]
signature.asc
Description: Digital signature
_______________________________________________ Openembedded-core mailing list [email protected] http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
