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 FILESPATH
where 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 https://foo.org/downloads/foo-1.0.tgz
).
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:
<project>/<release>/<distro>/<machine>/<package_arch>/<image>
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
DISTRO
configuration); - that each distro can be built for multiple
MACHINE
targets (eg.qemuarm64
,raspberrypi4
, etc.); - that given a specific
<project>/<release>/<distro>/<machine>
combination, binary packages for recipefoo/1.0-r0
are built only for a specificpackage_arch
(eg.aarch74-poky-linux-musl
); - that, given a specific
<project>/<release>/<distro>/<machine>/<package_arch>
combination, FILESPATH and/or SRC_URI for recipefoo/1.0-r0
could in theory be modified in different ways by different target image recipes, so that, f.e. we could have differentfoo.conf
files used in different images (we are not sure of this last assumption)
Are our assumptions correct (including the last one)?