At this point, we have addressed all we need to address prior to generating the image. The next two requirements are addressed during the final packaging of the release.
By releasing the version of the OpenEmbedded build system and the layers used during the build, you will be providing both compilation scripts and the source code modifications in one step.
If the deployment team has a BSP layer and a distro layer, and those those layers are used to patch, compile, package, or modify (in any way) any open source software included in your released images, you might be required to to release those layers under section 3 of GPLv2 or section 1 of GPLv3. One way of doing that is with a clean checkout of the version of the Yocto Project and layers used during your build. Here is an example:
# We built using the fido branch of the poky repo $ git clone -b fido git://git.yoctoproject.org/poky $ cd poky # We built using the release_branch for our layers $ git clone -b release_branch git://git.mycompany.com/meta-my-bsp-layer $ git clone -b release_branch git://git.mycompany.com/meta-my-software-layer # clean up the .git repos $ find . -name ".git" -type d -exec rm -rf {} \;
One thing a development organization might want to consider
for end-user convenience is to modify
meta-yocto/conf/bblayers.conf.sample
to
ensure that when the end user utilizes the released build
system to build an image, the development organization's
layers are included in the bblayers.conf
file automatically:
# LAYER_CONF_VERSION is increased each time build/conf/bblayers.conf # changes incompatibly LCONF_VERSION = "6" BBPATH = "${TOPDIR}" BBFILES ?= "" BBLAYERS ?= " \ ##OEROOT##/meta \ ##OEROOT##/meta-yocto \ ##OEROOT##/meta-yocto-bsp \ ##OEROOT##/meta-mylayer \ "
Creating and providing an archive of the Metadata layers (recipes, configuration files, and so forth) enables you to meet your requirements to include the scripts to control compilation as well as any modifications to the original source.