Query: isar-mmdebstrap-target: arch or mach dependent?

[cedric.h...@siemens.com]

Hello,

We have found one machine layer doing the following in its machine.conf
file:

DISTRO_APT_SOURCES:append = " soc1.list"

Let's now consider the case where that layer supports another SoC and
where the hardware vendor has a separate feed. We would do the same but
with soc2.list

We are ok until we want to build images for soc1 and soc2 using the
same folder (most likely using multiconfig builds)

The catch is that each SoC would require its own isar-mmdebstrap-target
and sbuild-chroot-target

Unfortunately, these Isar recipes use ${DISTRO}-${DISTRO_ARCH} for
${WORKDIR}

It appears that the intention was for the bootstrap and sbuild to be
architecture-dependent but not machine-dependent?

Shouldn't machine.conf files refrain from adding sources and instead
have package/image recipes requiring additional feeds build & use a
different sbuild?

I however do not think we can inject custom apt sources in a custom
sbuild flavor, can we? If we implement such a mechanism, I assume we
would want to keep previously downloaded list files
(/var/lib/dpkg/lists) unmodified and get apt to fetch only feeds being
added?

As for rootfs.bbclass, we could keep rootfs_prepare continue to use the
bootstrap as starting point and extend it with relevant lists.

As a general comment, we don't seem to have a clean separation of
architecture-independent builds, arch-dependent builds and machine-
dependent builds ala Yocto. Correct?

Should we consider implementing such concepts in Isar?

Thanks
Cedric

PS: it should be noted that multiconfig builds are advertised in the
documentation.