RE: [PATCH v5 3/5] classes: allow more control over container image name and tag

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

Schild, Henning (T RDA IOT SES-DE, 14. Dezember 2021 22:12:
> Am Wed, 18 Aug 2021 18:22:02 +0200
> schrieb Jan Kiszka <jan.kiszka@siemens.com>:
> 
> > On 18.08.21 18:19, Anton Mikanovich wrote:
> > > 05.08.2021 19:09, Henning Schild wrote:
> > >> diff --git a/doc/user_manual.md b/doc/user_manual.md
> > >> index cf7dc2fee35e..e5c07bd41fc5 100644
> > >> --- a/doc/user_manual.md
> > >> +++ b/doc/user_manual.md
> > >> @@ -1070,14 +1070,14 @@ bitbake -c do_populate_sdk
> > >> mc:qemuarm-buster:isar-image-base
> > >>    - Load the SDK container image into the Docker Daemon
> > >>     ```
> > >> -docker load -i
> > >> build/tmp/deploy/images/qemuarm/sdk-debian-buster-armhf-docker-
> archive.tar.xz
> > >>
> > >> +docker load -i
> > >> build/tmp/deploy/images/qemuarm/isar-image-base-debian-buster-armhf-1.0-
> r0-docker-archive.tar.xz
> > >>
> > >>   ```
> > >>      - Run a container using the SDK container image (following
> > >> commands starting
> > >>      with `#~:` are to be run in the container)
> > >>     ```
> > >> -docker run --rm -ti --volume "$(pwd):/build"
> > >> isar-sdk-buster-armhf:latest
> > >> +docker run --rm -ti --volume "$(pwd):/build"
> > >> isar-image-base-debian-buster-armhf:1.0-r0
> > >>   ```
> > >>      - Check that cross toolchains are installed
> > >> diff --git a/meta/classes/image-sdk-extension.bbclass
> > >> b/meta/classes/image-sdk-extension.bbclass
> > >> index 426b92595554..fa15b588068c 100644
> > >> --- a/meta/classes/image-sdk-extension.bbclass
> > >> +++ b/meta/classes/image-sdk-extension.bbclass
> > >> @@ -80,7 +80,7 @@ do_populate_sdk() {
> > >>       # generate the SDK in all the desired container formats
> > >>       if [ -n "${sdk_container_formats}" ] ; then
> > >>           bbnote "Generating SDK container in
> > >> ${sdk_container_formats} format"
> > >> -        containerize_rootfs "${SDKCHROOT_DIR}"
> > >> "sdk-${DISTRO}-${DISTRO_ARCH}" "${sdk_container_formats}"
> > >> +        containerize_rootfs "${SDKCHROOT_DIR}"
> > >> "${sdk_container_formats}"
> > >>       fi
> > >>   }
> > >>
> > >
> > > This might be wrong. Containerized rootfs image and containerized
> > > sdk image are using the same name, so output files will be
> > > overwritten. Meantime normal non-containerized SDK image is still
> > > using sdk-*.tar.xz output file mask.
> > >
> >
> > Good catch, the resulting filename for the SDK should be kept (already
> > used downstream).
> 
> Not sure we can/should keep that. Might be for the
> RECIPE-API-CHANGELOG.md in fact. The name should be in the file and
> also in the container metadata "image-name". I guess with the SDK
> container we currently have the problem that one can not import the sdk
> and the image because they conflict on the "image-name" even if the
> filenames differ.
> 
> In fact Adriaan told be he has a patch to make the SDK a real image ...
> and not some "unrelated thingy". Adriaan please give me that patch, it
> might be the proper solution to the problem at hand.

This was supposed to be the first patch in my "OE-style image types" series,
but seems useful on its own. Posted (sdk: make SDK and image, typos included).
I'm sure that some file names are wrong, but on the other hand I found that
the manual was also wrong about where the extracted SDK is deployed, so maybe
this is a good opportunity to clean all that up...

Adriaan