RE: [PATCH v2] sdk: make SDK an image

["Schmidt, Adriaan" <adriaan.schmidt@siemens.com>]

Kiszka, Jan, 16. Dezember 2021 15:31:
> On 16.12.21 10:12, Schmidt, Adriaan (T RDA IOT SES-DE) wrote:
> > Kiszka, Jan, 15. Dezember 2021 12:55:
> >> On 15.12.21 11:55, Adriaan Schmidt wrote:
> >>> This derives the SDK from image.bbclass (currently it only
> >>> inherits rootfs), removing the custom packaging, and instead
> >>> relying on existing features of image.bbclass.
> >>> Note that because there is not tarxz-img IMAGE_TYPE, we switch
> >>> the SDK type to targz-img. This is only temporary, until we have
> >>> the OE-inspired imagetypes.
> >>
> >> Then the ordering is also wrong: First make sure we can keep the
> >> previous output format, then refactor.
> >>
> >> Meanwhile, we can think about how to hook the SDK image build into a
> >> task of another image build, so that we move in the right direction /wrt
> >> configuration.
> >
> > I had a look at OE. There the SDK is something generated by the target
> > image, but it's something quite complex, with lots of Python code and
> > stuff in libraries. But except for the Isar SDK being simpler, it's
> > following the same idea.
> >
> > I now think:
> > - The SDK should be generated by the target image recipe, but maybe
> >   more integrated than it currently is. (Put the logic currently in
> >   the sdkchroot recipe into the image-sdk-extension class, so we can
> >   easily use settings made in the target image recipe)
> > - The SDK should only be generated as tar[xz|gz], but not as container
> > - If someone wants an SDK image (container, development VM, ...),
> >   that would be a separate recipe further processing the SDK, and the
> >   user would need to create that recipe explicitly. I can imagine that
> >   for the default case, this SDK image recipe would only have two lines:
> >   include the target image recipe (to get all the SDK_* settings and the
> >   do_populate_sdk task) and include some new class that makes the
> >   adjustments to generate an "image containing the SDK" instead
> >   of the original target image.
> 
> But how do get from the tarball to the container image? You are
> suggesting to drop an existing and actually used interface
> (https://github.com/siemens/meta-iot2050/blob/master/conf/distro/iot2050-
> debian.conf#L48),
> but you do not provide an equally simple alternative yet. That can't be
> "someone downstream has to write a special class".

The CONTAINER_FORMATS of the current implementation introduce a partial
duplicate of IMAGE_FSTYPES (only supporting tarballs and containers), when
I think it should be using the existing imaging mechanisms. (Soon someone
will request their SDK in the form of a VM image with KDE and Eclipse
installed...)

My current draft requires a 2-line recipe for the SDK image, e.g. isar-image-sdk.bb:
---
SDK_TARGET_IMAGE = "isar-image-base"
inherit sdkimage
---
This depends on ${SDK_TARGET_IMAGE}:do_populate_sdk, so all SDK_[PRE]INSTALL
and other settings defining the SDK are in the target image recipe.
(It's still not ideal, because im my current implementation you can
ONLY customize the SDK image in the target image recipe and not in the
SDK image one...)

`bitbake isar-image-sdk` then generates SDK images as requested by SDK_FORMATS,
with the same semantics as IMAGE_FSTYPES, so in the example you linked you'd have to
request container-img and set CONTAINER_FORMATS to define which containers
you want (actually, my imagetypes-draft would later make all the container
image types first-class citizens, so that would bring you back to the current
way of defining things).

For a generic solution I see no way around having a separate image.
The current SDK-container generation calls parts of the imaging code
as a function. This sort of works (although Henning already stumbled
across some of the details when he worked on improving container imaging),
but it's not something we can do in general.

> And it's also unclear to me how to ensure that container images are
> generated corresponding to the specific target images.

I hope it's become a little clearer...

Adriaan