Yocto Sources Handling

Preamble

THE YOCTO PROJECT. IT’S NOT AN EMBEDDED LINUX DISTRIBUTION, IT CREATES A CUSTOM ONE FOR YOU.

The Yocto Project (YP) is an open source collaboration project that helps developers create custom Linux-based systems regardless of the hardware architecture.

The project provides a flexible set of tools and a space where embedded developers worldwide can share technologies, software stacks, configurations, and best practices that can be used to create tailored Linux images for embedded and IOT devices, or anywhere a customized Linux OS is needed.

https://www.yoctoproject.org/

Sources in Yocto

To build the specific packages (bash, linux kernel, qtcreator) yocto recipes include SRC_URI information. As the name says it has the URI for the sources, and while that also includes locally held and provided files in form of configs, patch and patch sets, its primary function is to point to the URL of the source repository - in the current times that’s usually git repository somewhere “out there”.

These sources will always be reloaded, and for intended “repeatability” of Yocto builds - what would a distribution be good for that tomorrow is different to the one that worked today? - will be cleaned and purged from any changes made in fiddeling around.

If this is recognized and understood it is easy to see why Yocto is NOT a development platform. It also makes it clear why it is needed or imperative for users to provide their own repositories in the SRC_URI, as what, e.g. Ka-Ro provides with our BSP, is just a basic starting point. This leads to the requirement of users to proper git skills as a must.

Developing on a local git repository, that includes one own changes and provides state tracking, that allows forking of one owns solutions, bug fixes that required but not yet integrated by the community, be it kernel, bash, or any other rootfs integrated (GNU) tool are the end all and be all of successful Yocto solution development. The local git repository allows Yocto to pull the state as required while developing, and serves as a base for a patch set when making the Yocto “public”.

Here “public” doesn’t mean open to everyone but means to have a release available, though it might include the customers right to code as granted by GPL and other F/OSS licences, thus layers provided with ease are advantageous. To revert in a “public” release to the general git repository (e.g. of bash) and just adding the patch-set to the base tag (e.g. $BASH_VERSION = 4.4.12(1)-release) it provides repeatability, and a longterm base and yet offers the state as distributed to the device internally and (if the customer so wishes) externally.