[OE-core] [RFC] Utilizing LAYERVERSION_ to identify breaking changes to a layer

Flanagan, Elizabeth elizabeth.flanagan at intel.com
Thu Jun 20 22:56:48 UTC 2013


I know I've run into this issue and I'm going to bet that other folks
have as well.

When running some sort of continuous integration system (in my case,
yocto-autobuilder), I need to build to at least two releases back. The
problem is, sometimes, local.conf and bblayers.conf requirements
change, for example, a layer needs a BBMASK for the prior release but
can't have it for the current one or a layer gets split so that I need
to add two directories to BBLAYERS as opposed to just the one that I
used a few commits back. I currently have no great way of figuring
that out and it has causes immense amounts of pain.

I'd like to propose extending LAYERVERSION (which is already utilized
in oe-core as LAYERVERSION_core) out to other layers.

meta-angstrom LAYERVERSION_angstrom
meta-baryon LAYERVERSION_baryon
meta-beagleboard LAYERVERSION_beagleboard
meta-browser LAYERVERSION_browser
meta-fsl-arm LAYERVERSION_fsl-arm
meta-fsl-ppc LAYERVERSION_fsl-ppc
meta-guacamayo LAYERVERSION_guacamayo
meta-intel LAYERVERSION_intel
meta-minnow LAYERVERSION_minnow
meta-ti LAYERVERSION_ti
meta-xilinx LAYERVERSION_xilinx
meta-yocto LAYERVERSION_yocto

For bsp layers with multiple machine layers, like meta-intel or
meta-xilinx, I'd suggest something like:

LAYERVERSION_layername_machinename
e.g.
LAYERVERSION_intel_nuc
LAYERVERSION_xilinx_kc705

I'll be happy to do the above layers if folks approve of this
addition. Or, alternatively, if anyone has a better suggestion to be
able to identify breaking changes, I'm all ears.

-b

-- 
Elizabeth Flanagan
Yocto Project
Build and Release



More information about the Openembedded-core mailing list