The distributable's host-compiled pieces (launcher bin, libapplauncher.so, jlink runtime) are linked against Arch's glibc 2.38/libstdc++ — bookworm has 2.36/3.4.30, so a straight repackage silently exits 1 at launch. dist/bookworm-compat/ holds bookworm-built replacements (launcher-bin, libapplauncher.so, runtime/) extracted once from the known-good 0.1.0-1 deb; make-deb.py injects them into the tar stream without touching the build tree. Verified in a bookworm container: apt install -> ii, zero unresolved libs, app stays up 30s under Xvfb, build 6efec57.
- setup-standalone.sh: falls back to system python3 -m venv + pip when
uv isn't installed (Debian/Ubuntu path; verified on clean bookworm).
- dist/Dockerfile.debian: debian:bookworm build env for :app:packageDeb
(needs fakeroot + /usr/share/desktop-directories — both baked in; the
dir gap made jpackage's postinst fail with exit 3 on minimal systems).
- dist/make-release.sh: clean source tarball from HEAD.
- INSTALL-debian.md: end-to-end install for friends (source tree must
stay on disk — the app spawns the engine from it via SHONAR_REPO).
Verified on real Debian 12 in Docker: :app:packageDeb builds
shonar-desktop_0.1.0-1_amd64.deb, apt installs it, setup-standalone.sh
provisions the engine (venv+pip path, model fetch, boot smoke test),
and the packaged binary launches under Xvfb.