[Buildroot] [PATCH] fs/oci: entrypoint and command are space-separated lists

[Peter Korsgaard]

>>>>>   <yann.morin at orange.com> writes:

 > From: "Yann E. MORIN" <yann.morin at orange.com>
 > The prompt and variable name for the OCI "entrypoint arguments" are
 > somewhat incorrect. Indeed, they are in fact use to set the image
 > "command". Yet, using "command" would be confusing too, because the
 > interplay between entrypoint and command is tricky [0].

 > TL-DR; when both entrrypoint and command are set, command acts as

s/entrrypoint/entrypoint/

> arguments passed to the entrypoint.

 > Additionally, we currently can only pass a single item as either
 > entrypoint or command. This precludes passing actual arguments to the
 > entrypoint, or passing multiple arguments as command.

 > For example:
 >     BR2_TARGET_ROOTFS_OCI_ENTRYPOINT="/bin/tini -g -p SIGTERM --"
 >     BR2_TARGET_ROOTFS_OCI_ENTRYPOINT_ARGS="/usr/bin/env sh"

 > generates an images with (only relevant fileds are included below):

s/fileds/fields/

 >     {
 >         "config": {
 >             "Entrypoint": [ "/bin/tini -g -p SIGTERM --" ],
 >             "Cmd": [ "/usr/bin/env sh" ]
 >         }
 >     }

 > This is obviously incorrect, and not what one would expect:

 >     {
 >         "config": {
 >             "Entrypoint": [ "/bin/tini", "-g", "-p", "SIGTERM --" ],
 >             "Cmd": [ "/usr/bin/env", "sh" ]
 >         }
 >     }

 > Fix that by passing as-many --entrypoint or --cmd as there are
 > space-separated items in the corresponding lists.

 > [0] https://docs.docker.com/engine/reference/builder/#understand-how-cmd-and-entrypoint-interact

 > Signed-off-by: Yann E. MORIN <yann.morin at orange.com>
 > Cc: Sergio Prado <sergio.prado at e-labworks.com>
 > Cc: Matthew Weber <matthew.weber at collins.com>
 > ---
 >  fs/oci/oci.mk | 4 ++--
 >  1 file changed, 2 insertions(+), 2 deletions(-)

 > diff --git a/fs/oci/oci.mk b/fs/oci/oci.mk
 > index aa81920d36..f98db0a8c8 100644
 > --- a/fs/oci/oci.mk
 > +++ b/fs/oci/oci.mk
 > @@ -15,13 +15,13 @@ OCI_SLOCI_IMAGE_OPTS += $(and $(GO_GOARM),--arch-variant v$(GO_GOARM))
 >  # entrypoint
 >  OCI_ENTRYPOINT = $(call qstrip,$(BR2_TARGET_ROOTFS_OCI_ENTRYPOINT))
 >  ifneq ($(OCI_ENTRYPOINT),)
 > -OCI_SLOCI_IMAGE_OPTS += --entrypoint "$(OCI_ENTRYPOINT)"
 > +OCI_SLOCI_IMAGE_OPTS += $(patsubst %,--entrypoint %,$(OCI_ENTRYPOINT))
 >  endif
 
 >  # entrypoint arguments
 >  OCI_ENTRYPOINT_ARGS = $(call qstrip,$(BR2_TARGET_ROOTFS_OCI_ENTRYPOINT_ARGS))
 >  ifneq ($(OCI_ENTRYPOINT_ARGS),)
 > -OCI_SLOCI_IMAGE_OPTS += --cmd "$(OCI_ENTRYPOINT_ARGS)"
 > +OCI_SLOCI_IMAGE_OPTS += $(patsubst %,--cmd %,$(OCI_ENTRYPOINT_ARGS))

It indeed makes sense to split the entrypoint on white space, but for
the args (cmd) it exchanges one set of breakage for another -
E.G. sometimes people want to run sh -c "my shell logic goes here".

I'm not sure what to do about that though. As you are not quoting the
arguments you cannot even set it to stuff without white space but ith
shell characters, E.G. ENTRYPOINT="sh -c" ARGS="date;date" as the ; gets
enterpreted in the call to sloci-image.

In general I'm not sure how much value the oci support brings over just
doing:

docker import -c '<Dockerfile command>' output/images/rootfs.tar <name>:<tag>

-- 
Bye, Peter Korsgaard