Re: [meta-virtualization][PATCH 2/2] container-image-multiarch: add helper recipe

On Tue, Jun 9, 2026 at 2:53 PM Bruce Ashfield <[email protected]>
wrote:

> While I wait for my system level testing to complete, I'm going through
> the pending patches.
>
> This one brought a question to mind.
>
> On Wed, Jun 3, 2026 at 8:41 PM Tim Orling via lists.yoctoproject.org
> <[email protected]> wrote:
>
>> Similar to core-image-ptest.bb, this recipe uses mcextend to add
>> multiarch support for any recipe in CONTAINER_IMAGES variable which is
>> populated by the CONTAINER_IMAGES_META_VIRT variable in
>> container-image-packagelists.inc.
>>
>> Signed-off-by: Tim Orling <[email protected]>
>> ---
>>  .../images/container-image-multiarch.bb       | 25 +++++++++++++++++++
>>  1 file changed, 25 insertions(+)
>>  create mode 100644 recipes-containers/images/
>> container-image-multiarch.bb
>>
>> diff --git a/recipes-containers/images/container-image-multiarch.bb
>> b/recipes-containers/images/container-image-multiarch.bb
>> new file mode 100644
>> index 00000000..d3b586f4
>> --- /dev/null
>> +++ b/recipes-containers/images/container-image-multiarch.bb
>> @@ -0,0 +1,25 @@
>> +inherit features_check
>> +REQUIRED_DISTRO_FEATURES = "vcontainer"
>> +
>> +require conf/distro/include/container-image-packagelists.inc
>> +
>> +DESCRIPTION += "Enable building the ${MCNAME} multiarch image."
>> +SUMMARY ?= "${MCNAME} multiarch image."
>> +HOMEPAGE ?= "https://www.yoctoproject.org/"
>> +LICENSE ?= "MIT"
>> +LIC_FILES_CHKSUM ?=
>> "file://${COREBASE}/meta/COPYING.MIT;md5=3da9cfbcb788c80a0384361b4de20420"
>> +
>> +
>> +CONTAINER_IMAGES = "${CONTAINER_IMAGES_META_VIRT}"
>>
>
> This seems oddly tightly coupled to the .inc in the other patch. What's
> the value
> of that list being in the .inc and then consuming it here (when there are
> no other
> consumers).
>

You bring up a good point. In the ptest case there are multiple recipes
(core-image-ptest, core-image-ptest-fast, core-image-ptest-all), but in our
case we only have one consumer (containers-image-multiarch).


>
> What would be the future consumers of the variable/list ?
>
> If this was to be something overridable, shouldn't that be a ?=
> assignement ?
>

Also a good point. I'll fix both in v2.


>
> Bruce
>
>
>
>> +
>> +inherit oci-multiarch
>> +
>> +BBCLASSEXTEND = "${@' '.join(['mcextend:'+x for x in
>> d.getVar('CONTAINER_IMAGES').split()])}"
>> +
>> +OCI_MULTIARCH_RECIPE = "${MCNAME}"
>> +OCI_MULTIARCH_PLATFORMS = "aarch64 x86_64"
>> +
>> +python () {
>> +    if not d.getVar("MCNAME"):
>> +        raise bb.parse.SkipRecipe("No class extension set")
>> +}
>> --
>> 2.54.0
>>
>>
>> -=-=-=-=-=-=-=-=-=-=-=-
>> Links: You receive all messages sent to this group.
>> View/Reply Online (#9848):
>> https://lists.yoctoproject.org/g/meta-virtualization/message/9848
>> Mute This Topic: https://lists.yoctoproject.org/mt/119639260/1050810
>> Group Owner: [email protected]
>> Unsubscribe: https://lists.yoctoproject.org/g/meta-virtualization/unsub [
>> [email protected]]
>> -=-=-=-=-=-=-=-=-=-=-=-
>>
>>
>
> --
> - Thou shalt not follow the NULL pointer, for chaos and madness await thee
> at its end
> - "Use the force Harry" - Gandalf, Star Trek II
>
>