Create a somewhat standalone installable bundle

[karalabe]

Long term it would be nice to have some OS specific installers ala apt, homebrew, etc to pull this package. That's a lot of effort and a lot of maintenance we don't want to pay now. Cloning the github repo and building is a tad too many steps involved, so my best idea for starters is to publish the emulator on crates.io. That way we can at least do cargo install as a shorthand that should work on all platforms. Still requires Rust and whatnot, but it's one step closer to the ideal which is also cross platform.

[karalabe]

Alternatively, an interesting question is whether we can bundle with docker. The idea being to somehow avoid having to install dependencies of QEMU and other crap like it across different OSes.

[karalabe]

I read through main.rs first, and the good news is your QEMU usage is completely vanilla: direct -kernel/-initrd boot (so no UEFI/edk2 firmware blobs on the arm64 path), virtio-blk + virtio-net, SLIRP with one hostfwd, serial on stdio, and qemu-img only for the initial create -f qcow2. That profile is trivially bundleable, which makes the answer pretty clean:

Bundle QEMU into the app as Tauri sidecars, and let the Tauri bundler produce the per-OS artifact. Tauri has first-class support for this (bundle.externalBin): the qemu binaries ship inside the .app/.msi/AppImage next to your launcher, the launcher resolves the sidecar path first and falls back to $PATH (so cargo run dev flow and distro-qemu power users keep working). One artifact per OS, zero prerequisites for users, and combined with the firmware auto-fetch discussion earlier, the entire README "Prerequisites" section collapses to "download the app".

The key to keeping it low maintenance is to never build QEMU yourself; source prebuilt binaries per platform:

• Windows: the official installers (the Weil builds linked from qemu.org) are a self-contained directory. CI downloads the installer, extracts with 7z, cherry-picks qemu-system-{aarch64,x86_64}.exe, qemu-img.exe, the DLLs, and share/, pins a version+hash. Done.
• macOS: brew install qemu in CI, then a dylibbundler pass to copy the dylib closure into the bundle and rewrite paths to @executable_path. That's one static script; Homebrew does all the actual building and updating.
• Linux: this is where your "10 distro builders and deplists" fear dies: don't do distro packages at all. Ship one AppImage (Tauri emits it natively, and it already has to bundle webkit2gtk anyway, which is your worst Linux dep). apt install qemu-system on an oldest-supported CI base (Ubuntu 22.04), copy the binaries in, and let linuxdeploy resolve their .so closure into the image like it does for the webview. Runs on every glibc distro from that base forward. An optional .deb for the apt crowd can come later; it's a nicety, not a requirement.

Two details from your actual invocation: ship share/qemu too, since x86 -kernel boot still goes through SeaBIOS/linuxboot_dma.bin (it's a few MB, or you trim roms with romfile=), and qemu-img rides along for free from the same sources, though if you ever want to drop it, writing an empty qcow2 header with a virtual-size ceiling is ~100 lines of Rust.

On your two candidate ideas, both fail the brief for the desktop product: Docker turns a GUI hypervisor app into a headless nested-virtualization problem (on macOS/Windows, Docker itself is a Linux VM, so no KVM inside, TCG-slow boots, plus Docker Desktop is a bigger install than QEMU), though a headless image might be worth having later purely for CI of app developers. crates.io doesn't address QEMU at all, adds a Rust toolchain plus webkit2gtk-dev to every user's machine, and the 10MB crate limit wouldn't even hold the sidecars; publish the launcher crate if you like as a source path, but it's not distribution.

I'd also resist the tempting "native hypervisor per OS" route (Virtualization.framework on macOS, cloud-hypervisor on Linux): vz has no host port forwarding (your hostfwd on 127.0.0.1:18181 is load-bearing), no qcow2, and no cross-arch TCG, so you'd be writing a userspace NAT and forking the backend matrix three ways. QEMU everywhere is one command line, one behavior, with accel fallback already handled by your -accel list.

Housekeeping: QEMU is GPLv2, and bundling unmodified binaries as a separately spawned process next to your proprietary launcher is clean mere-aggregation; keep the license texts in the bundle and mirror the exact upstream source tarball for whatever version you ship (the public firmware-releases repo is a fine place). Expect the installers to grow to roughly 80-150MB compressed with both guest arches included, which is unremarkable for a dev tool; if that ever bothers you, bundling only the host-native arch and treating cross-arch as a PATH-qemu power feature is the easy trim.