what is the purpose and future of crun-wasm - asking for (a friend) Debian packaging :) ? about crun HOT 5 OPEN

Debian maintainer for crun and WasmEdge, and comaintainer for podman here :)

I think this is a bit of a "crun API" question that applies to both what crun is intended to ship, and thus what podman should be be using. Basically:

1. As far as I can tell, crun does not look at argv[0], and the build system does not install a crun-wasm symlink. The main crun binary simply dlopen()s libwasmedge (etc.).
2. The crun RPM spec does install a symlink, in a separate "crun-wasm" package, that also depends on WasmEdge.
3. In Debian, we configure with WasmEdge but do not ship a crun-wasm package, nor a symlink at the moment. The "crun" package Suggests: libwasmedge0.
4. However, as evident by Eugen's bug report, podman seems to rely on the existence of "crun-wasm" in the $PATH. This is a change in behavior compared what it used to in the past (and hence, a regression: wasm containers used to work out-of-the-box in Debian; now they don't).

Our goal as integrators/distributors is to minimize divergence with upstream, and ideally with other distributions, and install binaries where folks will expect them to be, and to avoid unnecessary cruft.

It is not super hard to follow the RPM packaging here. However, the fact that this symlink business happens only in the RPM spec and not e.g. in Makefiles, gives me pause. The solution does not seem super clear either: crun has all kinds of other dynamically loaded (dlopen) features (e.g. criu), are we supposed to create a matrix of symlinks in that way? Plus, how is this all going to fit with UAPI's ELF notes implementation for dlopen'ed dependencies, cf. systemd/systemd#32234?

So all in all, I think we're in a situation where the crun/podman upstreams are perhaps not fully in-line? Is a /usr/bin/crun-wasm symlink part of "crun's API" for container engines? Or should podman attempt to use /usr/bin/crun for wasi instead of, or in addition to, /usr/bin/crun-wasm?

from crun.

@giuseppe @flouthoc PTAL

from crun.

So if I'm hearing you right, we should be shipping /usr/bin/crun-wasm -> crun in Debian -- either in the same "crun" package, or a separate "crun-wasm" package.

That's trivial to do in the Debian packaging (literally one line), but I'm wondering, shouldn't crun's "make install" also install this symlink for any other downstream users?

yes, I agree it is better to fix it in the crun Makefiles so it works also for users using make install

from crun.

So all in all, I think we're in a situation where the crun/podman upstreams are perhaps not fully in-line? Is a /usr/bin/crun-wasm symlink part of "crun's API" for container engines? Or should podman attempt to use /usr/bin/crun for wasi instead of, or in addition to, /usr/bin/crun-wasm?

we used a custom annotation before to tell crun to run the container in "wasm mode". That is still possible, but it is a kind of a crun specific hack.

Differently, I think having different names for the runtimes is clearer for the users of the OCI runtime as it appears like a different runtime. The fact that it is a symlink is just an implementation detail, the crun-wasm runtime could be something completely different.

From the Podman PoV, or any other engine, they are really using two different runtimes (crun and crun-wasm) so there is no special handling needed, no custom annotation or anything else. Just use a different binary.

from crun.

Thanks for the quick response! This makes sense :)

So if I'm hearing you right, we should be shipping /usr/bin/crun-wasm -> crun in Debian -- either in the same "crun" package, or a separate "crun-wasm" package.

That's trivial to do in the Debian packaging (literally one line), but I'm wondering, shouldn't crun's "make install" also install this symlink for any other downstream users?

from crun.