On Sat, May 11, 2024 at 11:16:00AM -0400, Reinhard Tartler wrote: > > I see three paths forward: > > 1) We do the same, creating a new (almost) empty package. > > 2) We ship a /usr/bin/crun-wasm symlink in the crun package. > > 3) We patch podman to use /usr/bin/crun instead of, or in addition to, > > /usr/bin/crun-wasm. > > > I think we should do either 1 or 2 to minimize divergence with upstream. My > preference would be 2 to enable an out-of-the box experience.
Well... divergence with _which_ upstream? I think that's basically the question here. Upstream crun has no notion of "crun-wasm", AFAIK. There is one "crun" binary that just dynamically loads libwasmedge with dlopen(), among a few other libraries we don't have in Debian yet, e.g. criu or krun. There is nothing in its autoconf/Makefiles to install a symlink, either. The RPM spec does that. Hence, the existence of "crun-wasm" is an RPM packaging detail that *is* a divergence by itself, I think. However, that detail is now encoded into podman upstream. (It's also unclear to me why they decided to generate and ship a symlink, rather than just a metapackage. Is it just for changing podman's error messages?) Perhaps it's worth bringing it up with both crun and podman upstreams, I don't think we're going to be the only distro dealing with this. (I can take care of that.) > Is there any reason to not have that symlink installed by default in the > `crun` package? Technically, not, that's not hard. It just feels... icky to ship a symlink just to cover a packaging decision made in a different package, by another distro, no? Faidon _______________________________________________ Pkg-go-maintainers mailing list [email protected] https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-go-maintainers
