[agl-discussions] RFC: Extracting meta-sota into a standalone project

Phil Wise phil at advancedtelematic.com
Tue Nov 8 06:09:36 EST 2016

Hi Stephane,

On 07.11.2016 14:36, Stephane Desneux wrote:
> On 07/11/16 11:53, Phil Wise wrote:
>> Hi,
>> At the moment we have code in meta-agl-extra that provides Over-the-Air
>> software updates.  This includes some board specific integrations (e.g.
>> configuring the R-Pi bootloader for OSTree), but the majority is quite
>> general (e.g. the image_types_ostree bbclass that creates OSTree images
>> directly using bitbake).
>> Under the AGL principle of upstream first, it would seem sensible to
>> have this work in a form that other projects could use, similar to the
>> way that meta-qt5, meta-amb and the FSL/Qualcomm/Intel/R-Pi BSPs are
>> developed.
>> My proposed split would be:
>> 1) Move everything that depends only on Yocto/Poky into a new
>> 'meta-sota' project, managed in public on github.  This would have
>> branches for each of the Yocto releases (Jethro/Krogoth/etc.).  This
>> would be pulled into AGL using the repo manifest.
> Some dependent layers should also land somewhere: meta-rust is the main one IIRC.

Would requiring that the end project (e.g. AGL) include the prerequisite
layers be reasonable?  An alternative would be to bundle meta-rust
inside meta-sota, but while this would simplify integration it could
cause problems if people already have meta-rust elsewhere in their project.

>> 2) Keep board specific integration work inside meta-agl-extra, unless it
>> can be upstreamed into the relevant BSP layer.
> We could do in meta-agl-extra and meta-agl-devel the same as we do in meta-agl
> with meta-agl-bsp: have layers meta-agl-bsp-extra and meta-agl-bsp-devel to
> support board specific addons (or BSP level shared addons, like kernel config
> fragments). We could create 2 features 'agl-bsp-extra' and 'agl-bsp-devel' for
> conditional inclusion in bblayers.conf.

Yep, makes sense.  I haven't looked into it closely, but it would it be
practical to use DISTRO_FEATURES to manage this and avoid creating more
new layers?

>> 3) Keep AGL integration in templates/feature/agl-sota, so new users have
>> the same simple getting started experience as they do now.
> +1 . dependencies between features as introduced by Jan-Simon and Ronan (see for
> example https://gerrit.automotivelinux.org/gerrit/#/c/6959/) may also help to
> keep things simple: agl-sota would depend on agl-bsp-extra :)

Yep, dependences would be really useful to make the 'first run'
experience here nice.



Phil Wise, ATS Advanced Telematic Systems GmbH
Kantstrasse 162, 10623 Berlin
Managing Directors: Dirk Pöschl, Armin G. Schmidt
Register Court: HRB 151501 B, Amtsgericht Charlottenburg

More information about the genivi-projects mailing list