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

[Jan Kiszka <jan.kiszka@siemens.com>]

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".

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

Jan

-- 
Siemens AG, T RDA IOT
Corporate Competence Center Embedded Linux