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