Missing `init.c` in `crates.io` releases

[drahnr]

The builtin init.c is not included in the release package as published on https://crates.io causing a build failure, at least with 1.19.0

[mtjhrc]

This is mostly known issue that has been plaguing libkrun 1.x releases on crates.io.

Among other discussions, this was discussed in #713 (the 1.18.2 release PR, which was superseded by 1.19.0) — @d-e-s-o hit the same problem and pointed out that cargo package for init-blob/ fails because the init C sources aren't present. That discussion led to #714, which added the init-blob cargo feature gate so the bundled init can be disabled.

Current solutions for 1.19.0:

1. Build with default-features = false to disable the init-blob feature entirely. This is useful if you're providing your own init binary or booting for virtio-blk anyway — I think @d-e-s-o's use case is exactly this (they use a custom init and don't want the default blob bloating their binary). You could then inject the init binary at runtime via krun_fs_add_overlay_file().
2. Set KRUN_INIT_BINARY_PATH at build time to point to a pre-built init binary. This skips the C compilation entirely: KRUN_INIT_BINARY_PATH=/path/to/init cargo build

We are working on resolving this on main (upcoming libkrun 2.0). The current direction is that krun-init-blob will be a separate crate (or shared library if you are linking dynamically) that you manually depend on and init is now rewritten in Rust — #670.

That being said if someone comes up with a better way to package 1.x in a better way we could release that in 1.19.1 I think @slp (who manages the releases) would be open.

[nohajc]

@mtjhrc The minimal fix should be just to move init.c into the new init-blob crate.

I have that implemented and was planning to open a PR.