Openembedded Core Discussions
 help / color / mirror / Atom feed
From: Richard Purdie <richard.purdie@linuxfoundation.org>
To: openembedded-core <openembedded-core@lists.openembedded.org>
Subject: RFC: Layer tooling brainstorming
Date: Mon, 18 Apr 2011 07:17:01 +0100	[thread overview]
Message-ID: <1303107421.5518.45.camel@rex> (raw)

Layer Tooling for OpenEmbedded
==============================

As we move forward with encouraging the use of metadata layers, a number
of issues are appearing which imply the need for either infrastructure
improvements to the layer construction, or better tools to handle the
layers. The OS TSC discussed layers and layer tooling at the face to
face TSC meeting in San Francisco. Some example problems that were
identified that currently need addressing in some form are:

* There is no dependency information between layers (layer X depends on 
  layer Y and Z)
* There is no version information present (layer X needs version A of 
  layer Y)
* There is no layer "ABI" version number present in layers
* Layer specific sanity checks? (other types of sanity checks on Yocto 
  1.1 roadmap)
* Ability to fetch layers from other repositories
  - Multi SCM?
  - Use bitbake fetcher?
* Ability to generate repositories representing composited layers (Poky,
  RP has hacky scripts)
* Tool to seperate patch into one for different composited parts
* Ability to include partial components of repositories (e.g. only 
  beagleboard from meta-ti)
* Tool to merge (flatten) several layers into one
* Able to visualise dependencies between layers
* When bitbake prints banner of branch/commit, need to cover all layer 
  components present
* bitbake -e on steroids to highlight differences due to layer changes? 
  (long term goal)

Implementation thoughts:

* This layer tooling probably belongs at a higher level on the stack 
  than bitbake itself
* Maybe need to split into "bootstrap" steps (e.g where pseduo is 
  established, layers downloaded etc)
* Need some kind of config file defining layer's properties or at least 
  enhance layer.conf significantly
* git submodules and repo should be looked at but due to specific needs 
  and ability to control tool evolution, likely need own tool.

This hopefully summarises the ideas we discussed in person, we therefore
need to start looking at how to move forward from here with this but I
wanted to document this for starters!

Cheers,

Richard





             reply	other threads:[~2011-04-18  6:19 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-04-18  6:17 Richard Purdie [this message]
2011-04-18  6:50 ` RFC: Layer tooling brainstorming Martin Jansa
2011-04-18  7:09   ` Richard Purdie
2011-04-18  8:01     ` Koen Kooi
2011-04-18  8:30       ` Martin Jansa
2011-04-18  7:33 ` Andreas Mueller
2011-04-18  8:27   ` Richard Purdie
2011-04-18 13:59 ` Paul Eggleton
2011-04-18 15:24   ` Chris Larson
2011-04-18 19:51 ` Jeremy Puhlman
2011-04-22 23:29 ` Jeremy Puhlman

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1303107421.5518.45.camel@rex \
    --to=richard.purdie@linuxfoundation.org \
    --cc=openembedded-core@lists.openembedded.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox