Re: RFC: Layer tooling brainstorming

[Richard Purdie <richard.purdie@linuxfoundation.org>]

On Mon, 2011-04-18 at 08:50 +0200, Martin Jansa wrote:
> On Mon, Apr 18, 2011 at 07:17:01AM +0100, Richard Purdie wrote:
> > 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)
> 
> maybe I've missed something, but
> * Parsing error when ie foo_1.0.bbappend is found, but foo_1.0.bb in
>   upper layer was upgraded to foo_1.1.bb
>
> This can cause big problems when distribution explicitly enables
> something in .bbappend with EXTRA_OECONF, and someone updates all
> layers, builds foo_1.1.bb and installs it on targets before noticing
> that foo_1.0.bbappend wasn't used. Then he has to bump PR after adding
> foo_1.1.bbappend to distro layer (to fix foo on targets), so I would
> prefer parsing error in this case (won't help if upper layer keeps both
> versions foo_1.0.bb and foo_1.1.bb ;/).
> 
> This should be combined with your 2nd point and person who changes
> versioned dependency on upper layer should check that all needed
> .bbappends still apply.

Agreed but I thought we already had a tool to handle at least some of
this though? Certainly integration of that with the above is essential
though.

Cheers,

Richard