[PATCH 0/2] Document the image-container class

[PATCH 0/2] Document the image-container class

[Antonin Godard]

Signed-off-by: Antonin Godard <antonin.godard@bootlin.com>
---
Antonin Godard (2):
      ref-manual/variables.rst: document the IMAGE_CONTAINER_NO_DUMMY variable
      ref-manual/classes.rst: document the image-container class

 documentation/ref-manual/classes.rst   | 51 ++++++++++++++++++++++++++++++++++
 documentation/ref-manual/variables.rst |  7 +++++
 2 files changed, 58 insertions(+)
---
base-commit: b7f5b8ee510eeec286f2b0daece2717245b5b177
change-id: 20251023-image-container-fdc6d79f6729

[PATCH 1/2] ref-manual/variables.rst: document the IMAGE_CONTAINER_NO_DUMMY variable

[Antonin Godard]

Added in OE-Core with commit f0645e172bb8 ("image-container.bbclass:
Error if not using linux-dummy").

Signed-off-by: Antonin Godard <antonin.godard@bootlin.com>
---
 documentation/ref-manual/variables.rst | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/documentation/ref-manual/variables.rst b/documentation/ref-manual/variables.rst
index 71fe11b83..ac7b85992 100644
--- a/documentation/ref-manual/variables.rst
+++ b/documentation/ref-manual/variables.rst
@@ -3955,6 +3955,13 @@ system and gives an overview of their function and contents.
       variable, see the :ref:`ref-classes-image_types`
       class file, which is ``meta/classes-recipe/image_types.bbclass``.
 
+   :term:`IMAGE_CONTAINER_NO_DUMMY`
+      When inheriting the :ref:`ref-classes-image-container` class, this variable
+      can be set to "1" to allow a :term:`PREFERRED_PROVIDER` for the Linux kernel
+      (``virtual/kernel``) different than ``linux-dummy``.
+
+      This variable should be set from a :term:`Configuration File`.
+
    :term:`IMAGE_DEVICE_TABLES`
       Specifies one or more files that contain custom device tables that
       are passed to the ``makedevs`` command as part of creating an image.

-- 
2.51.0

Re: [docs] [PATCH 1/2] ref-manual/variables.rst: document the IMAGE_CONTAINER_NO_DUMMY variable

[Quentin Schulz]

Hi Antonin,

Seems like the SMTP server only sent the mail to myself and not other 
recipients. I've got to stop using this corporate setup, it's only 
bringing me pain.

I've already removed what I told in patch 2 was to be scratched in patch 
1 ;)

On 12/12/25 11:22 AM, Antonin Godard via lists.yoctoproject.org wrote:
> Added in OE-Core with commit f0645e172bb8 ("image-container.bbclass:
> Error if not using linux-dummy").
> 
> Signed-off-by: Antonin Godard <antonin.godard@bootlin.com>
> ---
>   documentation/ref-manual/variables.rst | 7 +++++++
>   1 file changed, 7 insertions(+)
> 
> diff --git a/documentation/ref-manual/variables.rst b/documentation/ref-manual/variables.rst
> index 71fe11b83..ac7b85992 100644
> --- a/documentation/ref-manual/variables.rst
> +++ b/documentation/ref-manual/variables.rst
> @@ -3955,6 +3955,13 @@ system and gives an overview of their function and contents.
>         variable, see the :ref:`ref-classes-image_types`
>         class file, which is ``meta/classes-recipe/image_types.bbclass``.
>   
> +   :term:`IMAGE_CONTAINER_NO_DUMMY`
> +      When inheriting the :ref:`ref-classes-image-container` class, this variable
> +      can be set to "1" to allow a :term:`PREFERRED_PROVIDER` for the Linux kernel
> +      (``virtual/kernel``) different than ``linux-dummy``.
> +

This seems to imply to me the default is "linux-dummy" but that isn't 
the case. Why would anyone select linux-dummy? A few words or 
cross-referencing another part of the doc where this would be explained 
would be nice.

This also *could* imply that setting IMAGE_CONTAINER_NO_DUMMY to 0 is 
going to do automagic stuff for PREFERRED_PROVIDER but it isn't. I would 
add something like:

:term:`PREFERRED_PROVIDER` also needs to be explicitly specified for 
``virtual/kernel`` (e.g. ``linux-dummy``, ``linux-yocto``, ...).

> +      This variable should be set from a :term:`Configuration File`.
> +

Are you sure about that? This variable is handled from a recipe class, 
itself inherited only when the IMAGE_FSTYPES contains "container". The 
examples in meta-virtualization all have it set in an image recipe.

Cheers,
Quentin

Re: [docs] [PATCH 1/2] ref-manual/variables.rst: document the IMAGE_CONTAINER_NO_DUMMY variable

[Antonin Godard]

Hi,

On Tue Dec 16, 2025 at 11:04 AM CET, Quentin Schulz via lists.yoctoproject.org wrote:
> Hi Antonin,
>
> Seems like the SMTP server only sent the mail to myself and not other 
> recipients. I've got to stop using this corporate setup, it's only 
> bringing me pain.
>
> I've already removed what I told in patch 2 was to be scratched in patch 
> 1 ;)
>
> On 12/12/25 11:22 AM, Antonin Godard via lists.yoctoproject.org wrote:
>> Added in OE-Core with commit f0645e172bb8 ("image-container.bbclass:
>> Error if not using linux-dummy").
>> 
>> Signed-off-by: Antonin Godard <antonin.godard@bootlin.com>
>> ---
>>   documentation/ref-manual/variables.rst | 7 +++++++
>>   1 file changed, 7 insertions(+)
>> 
>> diff --git a/documentation/ref-manual/variables.rst b/documentation/ref-manual/variables.rst
>> index 71fe11b83..ac7b85992 100644
>> --- a/documentation/ref-manual/variables.rst
>> +++ b/documentation/ref-manual/variables.rst
>> @@ -3955,6 +3955,13 @@ system and gives an overview of their function and contents.
>>         variable, see the :ref:`ref-classes-image_types`
>>         class file, which is ``meta/classes-recipe/image_types.bbclass``.
>>   
>> +   :term:`IMAGE_CONTAINER_NO_DUMMY`
>> +      When inheriting the :ref:`ref-classes-image-container` class, this variable
>> +      can be set to "1" to allow a :term:`PREFERRED_PROVIDER` for the Linux kernel
>> +      (``virtual/kernel``) different than ``linux-dummy``.
>> +
>
> This seems to imply to me the default is "linux-dummy" but that isn't 
> the case. Why would anyone select linux-dummy? A few words or 
> cross-referencing another part of the doc where this would be explained 
> would be nice.
>
> This also *could* imply that setting IMAGE_CONTAINER_NO_DUMMY to 0 is 
> going to do automagic stuff for PREFERRED_PROVIDER but it isn't. I would 
> add something like:
>
> :term:`PREFERRED_PROVIDER` also needs to be explicitly specified for 
> ``virtual/kernel`` (e.g. ``linux-dummy``, ``linux-yocto``, ...).

When building an image that inherits the image-container class, it's preferred
that PREFERRED_PROVIDER_virtual/kernel is set to "linux-dummy" globally.

>> +      This variable should be set from a :term:`Configuration File`.
>> +
>
> Are you sure about that? This variable is handled from a recipe class, 
> itself inherited only when the IMAGE_FSTYPES contains "container". The 
> examples in meta-virtualization all have it set in an image recipe.

Indeed, setting this from the image recipe should be enough.

Rephrased to:

"""
When an image recipe inherits the :ref:`ref-classes-image-container`
class, it expects the :term:`PREFERRED_PROVIDER` for the Linux kernel
(``virtual/kernel``) to be set to ``linux-dummy`` from a
:term:`configuration file`. Otherwise, an error is triggered.

The :term:`IMAGE_CONTAINER_NO_DUMMY` variable allows the
:term:`PREFERRED_PROVIDER` variable to be set to another value, thus skipping
the check and not triggering the build error.

This variable should be set from the image recipe inheriting the
:ref:`ref-classes-image-container` class.

See the documentation of the :ref:`ref-classes-image-container` class for more
information on why setting the :term:`PREFERRED_PROVIDER` to ``linux-dummy`` is
advised with this class.
"""

Thanks,
Antonin

-- 
Antonin Godard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

Re: [docs] [PATCH 1/2] ref-manual/variables.rst: document the IMAGE_CONTAINER_NO_DUMMY variable

[Quentin Schulz]

On 12/16/25 11:50 AM, Antonin Godard wrote:
> Hi,
> 
> On Tue Dec 16, 2025 at 11:04 AM CET, Quentin Schulz via lists.yoctoproject.org wrote:
>> Hi Antonin,
>>
>> Seems like the SMTP server only sent the mail to myself and not other
>> recipients. I've got to stop using this corporate setup, it's only
>> bringing me pain.
>>
>> I've already removed what I told in patch 2 was to be scratched in patch
>> 1 ;)
>>
>> On 12/12/25 11:22 AM, Antonin Godard via lists.yoctoproject.org wrote:
>>> Added in OE-Core with commit f0645e172bb8 ("image-container.bbclass:
>>> Error if not using linux-dummy").
>>>
>>> Signed-off-by: Antonin Godard <antonin.godard@bootlin.com>
>>> ---
>>>    documentation/ref-manual/variables.rst | 7 +++++++
>>>    1 file changed, 7 insertions(+)
>>>
>>> diff --git a/documentation/ref-manual/variables.rst b/documentation/ref-manual/variables.rst
>>> index 71fe11b83..ac7b85992 100644
>>> --- a/documentation/ref-manual/variables.rst
>>> +++ b/documentation/ref-manual/variables.rst
>>> @@ -3955,6 +3955,13 @@ system and gives an overview of their function and contents.
>>>          variable, see the :ref:`ref-classes-image_types`
>>>          class file, which is ``meta/classes-recipe/image_types.bbclass``.
>>>    
>>> +   :term:`IMAGE_CONTAINER_NO_DUMMY`
>>> +      When inheriting the :ref:`ref-classes-image-container` class, this variable
>>> +      can be set to "1" to allow a :term:`PREFERRED_PROVIDER` for the Linux kernel
>>> +      (``virtual/kernel``) different than ``linux-dummy``.
>>> +
>>
>> This seems to imply to me the default is "linux-dummy" but that isn't
>> the case. Why would anyone select linux-dummy? A few words or
>> cross-referencing another part of the doc where this would be explained
>> would be nice.
>>
>> This also *could* imply that setting IMAGE_CONTAINER_NO_DUMMY to 0 is
>> going to do automagic stuff for PREFERRED_PROVIDER but it isn't. I would
>> add something like:
>>
>> :term:`PREFERRED_PROVIDER` also needs to be explicitly specified for
>> ``virtual/kernel`` (e.g. ``linux-dummy``, ``linux-yocto``, ...).
> 
> When building an image that inherits the image-container class, it's preferred
> that PREFERRED_PROVIDER_virtual/kernel is set to "linux-dummy" globally.
> 

Yes, but this isn't the default in bitbake.conf or anywhere for that 
matter so it *needs* to be set to something (linux-dummy would be the 
preferred one as typically containers do not run their own kernel).

>>> +      This variable should be set from a :term:`Configuration File`.
>>> +
>>
>> Are you sure about that? This variable is handled from a recipe class,
>> itself inherited only when the IMAGE_FSTYPES contains "container". The
>> examples in meta-virtualization all have it set in an image recipe.
> 
> Indeed, setting this from the image recipe should be enough.
> 
> Rephrased to:
> 
> """
> When an image recipe inherits the :ref:`ref-classes-image-container`
> class, it expects the :term:`PREFERRED_PROVIDER` for the Linux kernel
> (``virtual/kernel``) to be set to ``linux-dummy`` from a
> :term:`configuration file`. Otherwise, an error is triggered.
> 
> The :term:`IMAGE_CONTAINER_NO_DUMMY` variable allows the
> :term:`PREFERRED_PROVIDER` variable to be set to another value, thus skipping
> the check and not triggering the build error.
> 
> This variable should be set from the image recipe inheriting the
> :ref:`ref-classes-image-container` class.
> 

 From patch 2, image-container isn't to be inherited manually, but 
IMAGE_FSTYPES needs to have "container" in it. Though the end result is 
the same... not sure it's worth the complexity in the docs. Or maybe 
just remove everything after "image recipe" (keep the paragraph below 
here though...). Or say "by adding "container" to 
:term:`IMAGE_FSTYPES`"? See also first sentence in this suggested 
section ("When an image recipe inherits..."), probably would need the 
same clarification.

> See the documentation of the :ref:`ref-classes-image-container` class for more
> information on why setting the :term:`PREFERRED_PROVIDER` to ``linux-dummy`` is
> advised with this class.
> """

Cheers,
Quentin

Re: [docs] [PATCH 1/2] ref-manual/variables.rst: document the IMAGE_CONTAINER_NO_DUMMY variable

[Antonin Godard]

Hi,

On Tue Dec 16, 2025 at 12:01 PM CET, Quentin Schulz wrote:
[...]
>  From patch 2, image-container isn't to be inherited manually, but 
> IMAGE_FSTYPES needs to have "container" in it. Though the end result is 
> the same... not sure it's worth the complexity in the docs. Or maybe 
> just remove everything after "image recipe" (keep the paragraph below 
> here though...). Or say "by adding "container" to 
> :term:`IMAGE_FSTYPES`"? See also first sentence in this suggested 
> section ("When an image recipe inherits..."), probably would need the 
> same clarification.

Yes, just realized this… I'm reworking the class and variable documentation, to
say that IMAGE_FSTYPES is enough to use this class.

Antonin

-- 
Antonin Godard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

[PATCH 2/2] ref-manual/classes.rst: document the image-container class

[Antonin Godard]

Add documentation for the image-container class, which is a simple class
to generate an image suitable for creating a container.

This answers in part to questions asked in [YOCTO #14368].

Signed-off-by: Antonin Godard <antonin.godard@bootlin.com>
---
 documentation/ref-manual/classes.rst | 51 ++++++++++++++++++++++++++++++++++++
 1 file changed, 51 insertions(+)

diff --git a/documentation/ref-manual/classes.rst b/documentation/ref-manual/classes.rst
index a56a2f719..0097b7c46 100644
--- a/documentation/ref-manual/classes.rst
+++ b/documentation/ref-manual/classes.rst
@@ -1258,6 +1258,57 @@ The :ref:`ref-classes-image_types` class also handles conversion and compression
    :term:`IMAGE_FSTYPES`. This would also be similar for Virtual Box Virtual Disk
    Image ("vdi") and QEMU Copy On Write Version 2 ("qcow2") images.
 
+.. _ref-classes-image-container:
+
+``image-container``
+===================
+
+The :ref:`ref-classes-image-container` class is meant to be inherited in
+:doc:`image </ref-manual/images>` recipes. It provides relevant settings to
+generate an image ready for use with an :wikipedia:`OCI
+<Open_Container_Initiative>`-compliant container management tool.
+
+.. note::
+
+   This class does not build and install container management tools on the
+   target. Support for this is available in the :yocto_git:`meta-virtualization
+   </meta-virtualization>` layer.
+
+An image recipe inheriting this class should also add the ``container`` image
+type to the :term:`IMAGE_FSTYPES` variable::
+
+   IMAGE_FSTYPES += "container"
+
+This image type does not deploy anything specific in :term:`DEPLOY_DIR_IMAGE`,
+but will simply add ``tar.bz2`` to the image types.
+
+You must also set the :term:`PREFERRED_PROVIDER` for the Linux kernel to
+``linux-dummy`` in a :term:`configuration file`::
+
+   PREFERRED_PROVIDER_virtual/kernel = "linux-dummy"
+
+The ``linux-dummy`` recipes acts as a Linux kernel recipe but builds nothing. It
+is relevant in this case as a container image does not need to include a Linux
+kernel. Selecting it as the preferred provider for the kernel will also decrease
+build time.
+
+If desired, the :term:`IMAGE_CONTAINER_NO_DUMMY` variable can be set to "1" to
+skip the ``PREFERRED_PROVIDER_virtual/kernel`` check.
+
+After the image is built, the generated ``tar.bz2`` archive can be used in a
+container generation file. For example, to be used with :wikipedia:`Podman
+<Podman>` or :wikipedia:`Docker <Docker_(software)>`, a `container file
+<https://docs.docker.com/reference/dockerfile/>`__ could contain the following
+instructions:
+
+.. code-block:: dockerfile
+
+   FROM scratch
+   ADD ./image-container-qemux86-64.rootfs.tar.bz2 /
+   ENTRYPOINT /bin/sh
+
+This is suitable to build a container using our generated root filesystem image.
+
 .. _ref-classes-image-live:
 
 ``image-live``

-- 
2.51.0

Re: [docs] [PATCH 2/2] ref-manual/classes.rst: document the image-container class

[Quentin Schulz]

Hi Antonin,

On 12/12/25 11:22 AM, Antonin Godard via lists.yoctoproject.org wrote:
> Add documentation for the image-container class, which is a simple class
> to generate an image suitable for creating a container.
> 

Wrong order of patches, patch 1 uses the reflink created in this patch.

EDIT: and this patch depends on patch 1 as well, so just merge both of 
them into one patch, they are related anyway.

> This answers in part to questions asked in [YOCTO #14368].
> 
> Signed-off-by: Antonin Godard <antonin.godard@bootlin.com>
> ---
>   documentation/ref-manual/classes.rst | 51 ++++++++++++++++++++++++++++++++++++
>   1 file changed, 51 insertions(+)
> 
> diff --git a/documentation/ref-manual/classes.rst b/documentation/ref-manual/classes.rst
> index a56a2f719..0097b7c46 100644
> --- a/documentation/ref-manual/classes.rst
> +++ b/documentation/ref-manual/classes.rst
> @@ -1258,6 +1258,57 @@ The :ref:`ref-classes-image_types` class also handles conversion and compression
>      :term:`IMAGE_FSTYPES`. This would also be similar for Virtual Box Virtual Disk
>      Image ("vdi") and QEMU Copy On Write Version 2 ("qcow2") images.
>   
> +.. _ref-classes-image-container:
> +
> +``image-container``
> +===================
> +
> +The :ref:`ref-classes-image-container` class is meant to be inherited in
> +:doc:`image </ref-manual/images>` recipes. It provides relevant settings to
> +generate an image ready for use with an :wikipedia:`OCI
> +<Open_Container_Initiative>`-compliant container management tool.

such as....? podman and docker I assume, probably others.

> +
> +.. note::
> +
> +   This class does not build and install container management tools on the

s/does not build and install/neither builds nor installs/

> +   target. Support for this is available in the :yocto_git:`meta-virtualization

s/Support for this is/Those tools are/?

> +   </meta-virtualization>` layer.
> +
> +An image recipe inheriting this class should also add the ``container`` image
> +type to the :term:`IMAGE_FSTYPES` variable::
> +
> +   IMAGE_FSTYPES += "container"
> +

Isn't that done by image.bbclass already anyway? This class is 
automatically inherited when IMAGE_FSTYPES contains "container".

c.f. 
https://git.openembedded.org/openembedded-core/tree/meta/classes-recipe/image.bbclass#n20 
and 
https://git.openembedded.org/openembedded-core/tree/meta/classes-recipe/image.bbclass#n25 
?

> +This image type does not deploy anything specific in :term:`DEPLOY_DIR_IMAGE`,
> +but will simply add ``tar.bz2`` to the image types.
> +
> +You must also set the :term:`PREFERRED_PROVIDER` for the Linux kernel to

No. You *can* (and you typically want).

> +``linux-dummy`` in a :term:`configuration file`::
> +
> +   PREFERRED_PROVIDER_virtual/kernel = "linux-dummy"
> +> +The ``linux-dummy`` recipes acts as a Linux kernel recipe but builds 
nothing. It
> +is relevant in this case as a container image does not need to include a Linux
> +kernel. Selecting it as the preferred provider for the kernel will also decrease
> +build time.
> +
> +If desired, the :term:`IMAGE_CONTAINER_NO_DUMMY` variable can be set to "1" to
> +skip the ``PREFERRED_PROVIDER_virtual/kernel`` check.
> +

Ah scratch that review on patch 1, linux-dummy isn't the default.

> +After the image is built, the generated ``tar.bz2`` archive can be used in a
> +container generation file. For example, to be used with :wikipedia:`Podman

Being curious, where did you see "container generation file" being used? 
First time I see Containerfile/Dockerfile named this way. You could keep 
it but maybe specify that it's typically named Containerfile or 
Dockerfile so people know what we're talking about?

Cheers,
Quentin

Re: [docs] [PATCH 2/2] ref-manual/classes.rst: document the image-container class

[Antonin Godard]

Hi,

On Fri Dec 12, 2025 at 1:07 PM CET, Quentin Schulz wrote:
> Hi Antonin,
>
> On 12/12/25 11:22 AM, Antonin Godard via lists.yoctoproject.org wrote:
>> Add documentation for the image-container class, which is a simple class
>> to generate an image suitable for creating a container.
>> 
>
> Wrong order of patches, patch 1 uses the reflink created in this patch.
>
> EDIT: and this patch depends on patch 1 as well, so just merge both of 
> them into one patch, they are related anyway.

Yeah, I thought I was being smart by making sure the order was right, turns out
they should be merged together!

>> This answers in part to questions asked in [YOCTO #14368].
>> 
>> Signed-off-by: Antonin Godard <antonin.godard@bootlin.com>
>> ---
>>   documentation/ref-manual/classes.rst | 51 ++++++++++++++++++++++++++++++++++++
>>   1 file changed, 51 insertions(+)
>> 
>> diff --git a/documentation/ref-manual/classes.rst b/documentation/ref-manual/classes.rst
>> index a56a2f719..0097b7c46 100644
>> --- a/documentation/ref-manual/classes.rst
>> +++ b/documentation/ref-manual/classes.rst
>> @@ -1258,6 +1258,57 @@ The :ref:`ref-classes-image_types` class also handles conversion and compression
>>      :term:`IMAGE_FSTYPES`. This would also be similar for Virtual Box Virtual Disk
>>      Image ("vdi") and QEMU Copy On Write Version 2 ("qcow2") images.
>>   
>> +.. _ref-classes-image-container:
>> +
>> +``image-container``
>> +===================
>> +
>> +The :ref:`ref-classes-image-container` class is meant to be inherited in
>> +:doc:`image </ref-manual/images>` recipes. It provides relevant settings to
>> +generate an image ready for use with an :wikipedia:`OCI
>> +<Open_Container_Initiative>`-compliant container management tool.
>
> such as....? podman and docker I assume, probably others.
>
>> +
>> +.. note::
>> +
>> +   This class does not build and install container management tools on the
>
> s/does not build and install/neither builds nor installs/
>
>> +   target. Support for this is available in the :yocto_git:`meta-virtualization
>
> s/Support for this is/Those tools are/?
>
>> +   </meta-virtualization>` layer.
>> +
>> +An image recipe inheriting this class should also add the ``container`` image
>> +type to the :term:`IMAGE_FSTYPES` variable::
>> +
>> +   IMAGE_FSTYPES += "container"
>> +
>
> Isn't that done by image.bbclass already anyway? This class is 
> automatically inherited when IMAGE_FSTYPES contains "container".
>
> c.f. 
> https://git.openembedded.org/openembedded-core/tree/meta/classes-recipe/image.bbclass#n20 
> and 
> https://git.openembedded.org/openembedded-core/tree/meta/classes-recipe/image.bbclass#n25 
> ?
>
>> +This image type does not deploy anything specific in :term:`DEPLOY_DIR_IMAGE`,
>> +but will simply add ``tar.bz2`` to the image types.
>> +
>> +You must also set the :term:`PREFERRED_PROVIDER` for the Linux kernel to
>
> No. You *can* (and you typically want).
>
>> +``linux-dummy`` in a :term:`configuration file`::
>> +
>> +   PREFERRED_PROVIDER_virtual/kernel = "linux-dummy"
>> +> +The ``linux-dummy`` recipes acts as a Linux kernel recipe but builds 
> nothing. It
>> +is relevant in this case as a container image does not need to include a Linux
>> +kernel. Selecting it as the preferred provider for the kernel will also decrease
>> +build time.
>> +
>> +If desired, the :term:`IMAGE_CONTAINER_NO_DUMMY` variable can be set to "1" to
>> +skip the ``PREFERRED_PROVIDER_virtual/kernel`` check.
>> +
>
> Ah scratch that review on patch 1, linux-dummy isn't the default.

I haven't seen your review on patch 1 (locally or on lore.kernel.org), did you
forget to send it?

>> +After the image is built, the generated ``tar.bz2`` archive can be used in a
>> +container generation file. For example, to be used with :wikipedia:`Podman
>
> Being curious, where did you see "container generation file" being used? 

Nowhere else, I made that up I guess. I'll reword this and mention
Containerfile/Dockerfile.

> First time I see Containerfile/Dockerfile named this way. You could keep 
> it but maybe specify that it's typically named Containerfile or 
> Dockerfile so people know what we're talking about?

Thanks!
Antonin

-- 
Antonin Godard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

Re: [docs] [PATCH 2/2] ref-manual/classes.rst: document the image-container class

[Antonin Godard]

Hi,

On Fri Dec 12, 2025 at 1:07 PM CET, Quentin Schulz wrote:
> Hi Antonin,
>
> On 12/12/25 11:22 AM, Antonin Godard via lists.yoctoproject.org wrote:
>> Add documentation for the image-container class, which is a simple class
>> to generate an image suitable for creating a container.
>> 
>
> Wrong order of patches, patch 1 uses the reflink created in this patch.
>
> EDIT: and this patch depends on patch 1 as well, so just merge both of 
> them into one patch, they are related anyway.
>
>> This answers in part to questions asked in [YOCTO #14368].
>> 
>> Signed-off-by: Antonin Godard <antonin.godard@bootlin.com>
>> ---
>>   documentation/ref-manual/classes.rst | 51 ++++++++++++++++++++++++++++++++++++
>>   1 file changed, 51 insertions(+)
>> 
>> diff --git a/documentation/ref-manual/classes.rst b/documentation/ref-manual/classes.rst
>> index a56a2f719..0097b7c46 100644
>> --- a/documentation/ref-manual/classes.rst
>> +++ b/documentation/ref-manual/classes.rst
>> @@ -1258,6 +1258,57 @@ The :ref:`ref-classes-image_types` class also handles conversion and compression
>>      :term:`IMAGE_FSTYPES`. This would also be similar for Virtual Box Virtual Disk
>>      Image ("vdi") and QEMU Copy On Write Version 2 ("qcow2") images.
>>   
>> +.. _ref-classes-image-container:
>> +
>> +``image-container``
>> +===================
>> +
>> +The :ref:`ref-classes-image-container` class is meant to be inherited in
>> +:doc:`image </ref-manual/images>` recipes. It provides relevant settings to
>> +generate an image ready for use with an :wikipedia:`OCI
>> +<Open_Container_Initiative>`-compliant container management tool.
>
> such as....? podman and docker I assume, probably others.
>
>> +
>> +.. note::
>> +
>> +   This class does not build and install container management tools on the
>
> s/does not build and install/neither builds nor installs/
>
>> +   target. Support for this is available in the :yocto_git:`meta-virtualization
>
> s/Support for this is/Those tools are/?
>
>> +   </meta-virtualization>` layer.
>> +
>> +An image recipe inheriting this class should also add the ``container`` image
>> +type to the :term:`IMAGE_FSTYPES` variable::
>> +
>> +   IMAGE_FSTYPES += "container"
>> +
>
> Isn't that done by image.bbclass already anyway? This class is 
> automatically inherited when IMAGE_FSTYPES contains "container".
>
> c.f. 
> https://git.openembedded.org/openembedded-core/tree/meta/classes-recipe/image.bbclass#n20 
> and 
> https://git.openembedded.org/openembedded-core/tree/meta/classes-recipe/image.bbclass#n25 
> ?

Ah, so actually you're supposed to just add "container" to IMAGE_FSTYPES rather
than inheriting the class. I wonder why this was designed like this rather than
just a class inherit, it's not obvious/usual.

I will instruct to only set IMAGE_FSTYPES then.

Thanks,
Antonin

-- 
Antonin Godard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com