Re: [PATCH v2 0/5] Support multiple image types in one build

[Baurzhan Ismagulov <ibr@radix50.net>]

On Tue, Oct 05, 2021 at 11:08:56AM +0200, Henning Schild wrote:
> In fact having exactly one image type and using multiconfig is already
> very powerful. We have layers where we have custom image classes which
> include existing ones and are set as the "main type". That is super
> flexible already.

No question :) .


> I am not a fan of mc, but here we have a proposal that seems to want to
> defeat mc and is lacking a clear motivation. At least i do not fully
> understand why that change makes sense. The main point could be OE
> alignment which might be good enough but not really too important.

I guess we didn't communicate it clearly enough, this change doesn't remove the
existing infrastructure -- the current way is still supported. v2 did touch the
existing testcases -- in v3, we don't change them anymore and add a new case
for testing the new functionality.


> A simple array list is much less flexible. Imagine you want to have a
> wic-img and an ext4 and your rootfs contains "expand-on-first-boot",
> meaning wic will grow once on device ... while ext4 might need another
> ROOTFS_EXTRA/_SIZE. In fact one will likely even have different
> packages installed depending on the type. While packing the same rootfs
> into multiple images will work it is much nicer to adapt the content to
> the type. i.e. a container might need less of an init
> system/kernel/initrd or filesystem support, a wic will maybe need
> bootloader bits, and an ext4 will not need expand-on-first-boot (like
> container as well)

Thanks for the detailed example. For this use case, this approach is fine.

The motivation for multiple image types is that BSP vendors want to provide all
types of images with one image.bb and n machines, without permutations like
mc:machine1-sd mc:machine1-tgz mc:machine2-sd mc:machine2-tgz. This change
implements this use case. We'll send v3 soon.


With kind regards,
Baurzhan.