Re: [meta-virtualization][PATCH] crun: provide virtual-runc and honour CRUN_AS_RUNC

[Bruce Ashfield <bruce.ashfield@gmail.com>]

Hi Royyan,

Thanks for the patch, but the premise it's built on is the one thing
I need to push back on.

`virtual/runc` (and its RPROVIDES sibling `virtual-runc`) is a holdover
from when meta-virtualization carried two runc implementations in-tree,
opencontainers/runc and docker's own. Commit 7d6284a0 (2017)
introduced the abstraction so a build could set PREFERRED_PROVIDER to
pick which variant was the C-level runc binary. Once the two variants
were consolidated (cb2d4868 removed the "opencontainers" flavor,
ea15fd06 dropped runc-docker), the mechanism lost its purpose. It's on
a path to removal, not extension, and I'd rather not add new consumers.

For picking crun vs runc as the OCI runtime of a container engine, the
layer's mechanism today is `VIRTUAL-RUNTIME_container_runtime` (plus
the sibling VIRTUAL-RUNTIME_container_* variables) set in the profile
fragments under `conf/distro/include/`. `meta-virt-container-containerd.inc`
already ships with `VIRTUAL-RUNTIME_container_runtime ??= "crun"` -- that
is the intended way to make crun the default runtime, and no bbappend
or RPROVIDES is involved. The bbappend churn you're seeing in
downstreams is a symptom of that pattern not being documented well
enough, not of a missing RPROVIDES on crun.

That said, the second half of your patch is genuinely finding a bug:
`CRUN_AS_RUNC = "false"` reads as true today, because "false" is a
non-empty string in both the shell `-n` test and the python
`if d.getVar(...)` expansions. That fix is worth landing on its own.

Would you resubmit as a smaller patch that keeps just the
`bb.utils.to_boolean()` normalization for `CRUN_AS_RUNC`, without the
`RPROVIDES virtual-runc` addition? I'd also skip the comment
rewordings on the RCONFLICTS line -- the existing comment reads fine
and reworking it on a bugfix makes the change harder to review. I can
take that version as-is.

Cheers,

Bruce