Yocto Layer strategy for GDP (was: RE: [PATCH] meta-rvi: Add layers for RVI)

Stephen Lawrence stephen.lawrence at renesas.com
Mon May 9 09:53:56 EDT 2016

> -----Original Message-----
> From: genivi-projects-bounces at lists.genivi.org [mailto:genivi-projects-
> bounces at lists.genivi.org] On Behalf Of Andersson, Gunnar
> Sent: 06 May 2016 14:51
> To: Streif, Rudolf <rstreif at jaguarlandrover.com>; Changhyeok Bae
> <changhyeok.bae at gmail.com>
> Cc: leon at mip-labs.com; genivi-projects at lists.genivi.org
> Subject: Yocto Layer strategy for GDP (was: RE: [PATCH] meta-rvi: Add layers
> for RVI)


+1 on the creation of functional layers where it makes sense over copying
into meta-genivi-demo.

> This makes sense currently.  Just be mindful that the content has to do with
> RVI related technology, instead of a catch-all for any and all
> *EG-RVI* projects.  That is, EG projects might be somewhat independent
> from each other.  Otherwise this too may end up being a diverse repo that is
> either hard (or only undesirable) to reuse by those that only want a small
> subset of mostly independent features.
> In criticizing land-grabbing layers we should acknowledge that in GENIVI we
> also have a diversified layer/repo, meta-ivi, but it has a long tradition in
> GENIVI and predates AGL completely.  It is a an efficient way we can create a
> clearly defined baseline containing IVI-software that is also GENIVI
> compliant.
> Unless potential adopters start a conversation with us, like I attempted with
> AGL, then this likely won't change.

I think efficiency is a good word here. There will be times when there is benefit of 
components having their own layer, but there is also benefit of some centralisation 
of others in concentrating effort, coordination and let's not forget integration.

I tend to think meta-ivi took a pretty typical approach to yocto layering as a layer
that "collects up" tech and it doesn't actually contain that many BBs. They are limited 
to image definitions, component package groups (good use of yocto), lifecycle, 
compositor, common api, dlt, legacy gst 1.2.x and 3 external components (presumably
without recipes elsewhere). The rest are bbappends to external layers. 

As you say some of this will be historical from the transition to a yocto baseline when
the maintainers usefully created recipes for components that didn't have them. As
Genivi was the originator it seems natural that it defined those.

Of course down the road, with a more filled in Reference Architecture, more separation 
may make sense. There of course is also the opportunity to collaborate with other orgs.



More information about the genivi-projects mailing list