Re: [meta-virtualization][PATCH 7/7] app-container-curl: use multilayer mode; container-nonroot-user

Tim Orling <[email protected]> Fri, 03 Jul 2026 08:28:53 -0700
Newsgroups org.yoctoproject.lists.meta-virtualization
Message-ID <178309253300.29524.1959660853411369631.b4-reply@b4>
On 2026-06-12 11:23:51-07:00, Bruce Ashfield wrote:
> Hi Tim,
> 
> Wrap-up patch, mostly aligns curl with the new conventions. One real
> question, one observation.
> 
> On Fri, May 29, 2026 at 18:31 -0700, Tim Orling wrote:
> 
> > * Move to recipes-containers/images to show maintenance intent
> > * Switch to multilayer mode to more like the other "library"/"official"
> >   container recipes.
> > * Change OCI_IMAGE_TAG to "latest" for similar reasons.
> > * Change OCI_IMAGE_ENTRYPOINT_ARGS to "--help" to be more like upstream
> >   containers.
> 
> The directory move right. no issues. recipes-demo was always
> "here's an example", recipes-containers/images is "this is supported".
> Same for "easy" → "latest"; matches Docker convention.
> 
> The "--help" default is a small but a win ... running the image with
> no args now self-documents instead of trying to hit a probably-absent
> localhost:80.
> 
> > +OCI_LAYERS = "\
> > +    base:packages:base-files+base-passwd+netbase \
> > +    ${@bb.utils.contains('PACKAGECONFIG', 'dev', 'shell:packages:${CONTAINER_SHELL}', '', d)} \
> > +    curl:packages:curl+ca-certificates \
> > +"
> 
> [...]
> 
> > -CONTAINER_SHELL = "busybox"
> 
> This worries me. The old recipe had CONTAINER_SHELL = "busybox" at
> the top level, so the variable always had a value. The new recipe
> removes that line and only references ${CONTAINER_SHELL} inside the
> conditional shell layer.
> 
> In non-dev mode that's fine because the whole bb.utils.contains
> expression resolves to the empty string and the layer doesn't appear.
> 
> In dev mode the OCI_LAYERS line expands to:
> 
>     shell:packages:
> 
> …because nothing in the recipe (or in container-nonroot-user.bbclass)
> sets CONTAINER_SHELL. image-oci.bbclass's validator parses this as a
> three-field entry with empty content, so it doesn't bb.fatal — but no
> packages get added to the auto-derived IMAGE_INSTALL, and the
> resulting layer is empty. The container is silently shipped without
> a shell, which is exactly the thing dev mode is supposed to provide.
> 
> Two ways to fix:
> 
>   a) Add a default in the recipe near the PACKAGECONFIG declaration:
> 
>          CONTAINER_SHELL ??= "busybox"
> 
>      Then anyone enabling dev gets busybox by default and the variable
>      remains overridable.
> 
>   b) Push the default into container-nonroot-user.bbclass so every
>      recipe that inherits it gets a consistent shell value.
> 
> I'd lean (a) — the class shouldn't carry a shell concept; that's a
> per-recipe choice — but either works.
> 

Added classes/container-dev-mode.bbclass which sets CONTAINER_SHELL to
'busybox' when PACKAGECONFIG contains 'dev'. For hardened/production mode
it is recommended to add 'container-dummy-provides' to PACKAGE_EXTRA_ARCHS
and then the class falls back to 'busybox' if that is not set.

> > +OCI_IMAGE_RUNTIME_UID = "${@bb.utils.contains('PACKAGECONFIG', 'dev', '0', '${NONROOT_UID}', d)}"
> 
> This dev-mode-overrides-uid pattern also appears in 2/7 (python). It's
> clean here, and identical there — another candidate for the helper
> class refactor whenever the rootfs_fixup_var_volatile factor-out
> happens, since it's the same shape of "PACKAGECONFIG dev means root".
> 

Good point and this was refactored into container-dev-mode.bbclass.

> > +IMAGE_INSTALL:append = " curl ca-certificates"
> 
> Same series-level point as the earlier recipes — image-oci.bbclass
> now auto-derives this from OCI_LAYERS in v2 / master-next, so the
> line can go.

IMAGE_INSTALL lines removed in v2.

> 
> Bruce