From: "'cedric.hombourger@siemens.com' via isar-users" <isar-users@googlegroups.com>
To: "isar-users@googlegroups.com" <isar-users@googlegroups.com>
Cc: "Larson, Chris" <chris.larson@siemens.com>
Subject: Query: isar-mmdebstrap-target: arch or mach dependent?
Date: Thu, 13 Mar 2025 20:30:06 +0000 [thread overview]
Message-ID: <37553013e72583a26e512e7eff512ede741a7a04.camel@siemens.com> (raw)
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.
--
You received this message because you are subscribed to the Google Groups "isar-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to isar-users+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/isar-users/37553013e72583a26e512e7eff512ede741a7a04.camel%40siemens.com.
reply other threads:[~2025-03-13 20:30 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=37553013e72583a26e512e7eff512ede741a7a04.camel@siemens.com \
--to=isar-users@googlegroups.com \
--cc=cedric.hombourger@siemens.com \
--cc=chris.larson@siemens.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox