We (@pmoser and I, working on the IP compliance toolchain) need to find a way to uniquely tag different source files used by the same version/revision of a bitbake recipe across different machines and project releases (eg. recipe
foo/1.0-r0 that uses different versions of
file://foo.conf depending on the target machine and/or on the project release, because different stuff is prepended to the
foo.conf is looked for) .
The goal is to generate a single source package (say
foo_1.0-r0+sometag) out of a certain bb recipe (say
foo/1.0-r0) by including all possible patch, init script and conf file variants that depend on target machine and/or on project release, provided that the upstream source tarball is the same (eg.
foo-1.0.tgz downloaded from
We came up with the following tag tree to tag such variants that we need to put in our metadata model, and we would like to get feedback on that:
We are assuming:
- that a specific yocto project (identified by a certain git repo of a manifest that identifies a set of bb layers) can have multiple releases (each identified by a certain manifest revision);
- that each release may have multiple distros (each identified by a specific
- that each distro can be built for multiple
- that given a specific
<project>/<release>/<distro>/<machine>combination, binary packages for recipe
foo/1.0-r0are built only for a specific
- that, given a specific
<project>/<release>/<distro>/<machine>/<package_arch>combination, FILESPATH and/or SRC_URI for recipe
foo/1.0-r0could in theory be modified in different ways by different target image recipes, so that, f.e. we could have different
foo.conffiles used in different images (we are not sure of this last assumption)
Are our assumptions correct (including the last one)?