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

Streif, Rudolf rstreif at jaguarlandrover.com
Mon May 9 13:01:23 EDT 2016


I apologize for top-posting.

I cannot really understand where "the too many layers" fear comes from. I
have not heard any compelling argument why one should/must reduce the
number of layers used to build the system. In my opinion:

   1. It makes no sense whatsoever to copy recipes from maintained upstream
   layers into your own layers ("privatize them, as Gunnar called it). The
   argument of reducing complexity does not hold here. It increases complexity
   and maintenance effort.
   2. If there is a reasonable chance that a component can be reused in
   different contexts, it makes good sense to put it into its own layer. For
   example, RVI can be reused outside of automotive contexts e.g. for IoT etc.
   It would actually hinder the adoption if RVI were commingled into a
   meta-ivi etc. layer.
   3. The criticism of meta-ivi as a layer that "collects up tech" as Steve
   puts it hold true. It's an umbrella or compound layer that includes
   multiple sublayers including BSP layers. It makes things simpler as you
   only have to clone one repository form a git server but you still have to
   include every sublayer individually into your build environment. However,
   it commingles things that logically do not belong together: IVI middleware
   with BSPs and other stuff.
   4. Avoid "kitchen sink" layers putting everything into one or a few
   layers because of a perceived inconvenience of including many layers into
   the build environment. This is simply turning the clock back to
   OpenEmbedded Classic where all recipes were in one directory. Layers
   support re-usability and easier maintenance. Maintenance responsibilities
   can easily be divided among many maintainers.

:rjs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.genivi.org/pipermail/genivi-projects_lists.genivi.org/attachments/20160509/107a4a02/attachment.html>


More information about the genivi-projects mailing list