Make AppRun script dependency free

[lalten]

Currently rules_appimage uses an AppRun script created here:

rules_appimage/appimage/private/mkapprun.bzl

Lines 58 to 82 in bcd4c72

	apprun_lines.append('OWD="${OWD=$PWD}"') # remove when https://github.com/AppImage/type2-runtime/issues/23 is fixed
	apprun_lines.append('BUILD_WORKING_DIRECTORY="${BUILD_WORKING_DIRECTORY=$OWD}"')
	apprun_lines.append("export BUILD_WORKING_DIRECTORY")
	# Some environment variables set by Bazel at runtime that interfere with runfiles resolution need to be unset.
	# This can be important when running an AppImage under Bazel (e.g. for integration tests)
	# https://github.com/bazelbuild/bazel/blob/8.4.2/src/main/java/com/google/devtools/build/lib/runtime/commands/RunCommand.java#L193
	apprun_lines.append("unset JAVA_RUNFILES")
	apprun_lines.append("unset RUNFILES_MANIFEST_FILE")
	apprun_lines.append("unset RUNFILES_MANIFEST_ONLY")
	apprun_lines.append("unset TEST_SRCDIR")
	# Explicitly set RUNFILES_DIR to the runfiles dir of the binary instead of the appimage rule itself
	apprun_lines.append('thisdir="${0%/*}"') # Same as "$(dirname "$0")"
	apprun_lines.append('workdir="$thisdir/%s"' % get_workdir(ctx))
	apprun_lines.append('RUNFILES_DIR="${workdir%/*}"') # Get parent directory of workdir
	apprun_lines.append("export RUNFILES_DIR")
	# Run under runfiles
	apprun_lines.append('cd "$workdir"')
	# Launch the actual binary
	apprun_lines.append('exec "./%s" "$@"' % get_entrypoint(ctx))
	return "\n".join(apprun_lines) + "\n"

While there has been work to strip away some dependencies like "Don't call /usr/bin/dirname in AppRun" (#296) this still has some dependencies, most notably the shell interpreter /bin/sh itself.
This has prompted some workarounds like

rules_appimage/tests/cc_runfiles/container/BUILD

Lines 27 to 37 in bcd4c72

	# distroless "debug" images contain their shell at /busybox/sh, but the AppRun script uses a "/bin/sh" shebang
	pkg_mklink(
	name = "link_sh",
	link_name = "/bin/sh",
	target = "/busybox/sh",
	)
	pkg_tar(
	name = "link_sh.tar",
	srcs = [":link_sh"],
	)

If we didn't depend on a shell but had a compiled and statically linked AppRun instead, this would be a non-issue, and AppImages would work (with APPIMAGE_EXTRACT_AND_RUN=1) inside mostly-empty containers like https://github.com/GoogleContainerTools/distroless/tree/main/cc or even https://github.com/GoogleContainerTools/distroless/blob/main/base/README.md

[lalten]

Another option could be to (optionally?) bundle our own shell interpreter, e.g. an αcτµαlly pδrταblε εxεcµταblε (APE) dash (https://gitlab.arm.com/bazel/ape/-/blob/main/ape/cosmos/4.0.2.json#L39) (not sure if https://github.com/tweag/rules_sh provides an interpreter?)

[lalten]

I just learned about https://github.com/hermeticbuild/hermetic-launcher, also seems interesting

[lalten]

Investigation: replacing the shell AppRun with hermetic-launcher

TL;DR: hermetic-launcher would solve exactly what this issue asks for — a fully static, dependency-free AppRun (~16–30 KB, no libc, raw syscalls) that makes APPIMAGE_EXTRACT_AND_RUN=1 work in distroless/cc, distroless/base, or even scratch containers, killing the /bin/sh symlink workaround in tests/cc_runfiles/container/BUILD. But it does not yet cover everything our AppRun.sh does today, so it can't be a drop-in replacement without upstream features or residual logic on our side.

What works well

• Downstream API unchanged: appimage() / appimage_test() attrs stay the same; users just gain a transitive bazel_dep(name = "hermetic_launcher").
• Arch selection is automatic: launcher templates are selected via toolchain resolution against the target platform (launcher.compile(ctx, cfg = "target")), exactly analogous to how we select @appimage_runtime_<arch> today. No manual arch handling needed.
• Maintainability win inside rules_appimage: the fragile export -p | sed 's/^declare -x/export/' | grep -v ... pipeline, shell-quoting concerns, and the "which shell exists at runtime" bug class (cf. Don't call /usr/bin/dirname in AppRun #296) all disappear.
• Deterministic: launchers are produced by pure byte-patching of prebuilt templates, byte-identical from any host.

⚠️ Things NOT covered yet (the gaps)

1. Environment variable injection — the launcher only exports RUNFILES_DIR / RUNFILES_MANIFEST_FILE / JAVA_RUNFILES to the child. There's no mechanism to embed arbitrary env, so we'd lose:
   • the env attr and RunEnvironmentInfo from the wrapped binary,
   • the build-time env snapshot (-env.sh) that AppRun re-sources today.
2. No chdir into the workdir — AppRun currently cds into the runfiles workdir. Binaries relying on cwd-relative data access (rather than a runfiles library) would break.
3. BUILD_WORKING_DIRECTORY / $OWD fallback chain — the carefully-tuned BUILD_WORKING_DIRECTORY := $BUILD_WORKING_DIRECTORY | $OWD | $PWD logic (incl. the type2-runtime OWD quirk, OWD is not set when APPIMAGE_EXTRACT_AND_RUN=1 AppImage/type2-runtime#23) has no launcher equivalent. Tools resolving user-relative CLI paths would regress.
4. Unsetting stale Bazel vars — AppRun unsets JAVA_RUNFILES, RUNFILES_MANIFEST_FILE, RUNFILES_MANIFEST_ONLY, TEST_SRCDIR. The launcher instead gives env-provided runfiles sources precedence, so when an AppImage runs under an outer Bazel invocation (integration tests), it could resolve the wrong runfiles tree.
5. Runfiles discovery vs. AppDir layout — the launcher looks for <executable>.runfiles/ adjacent to itself, but our AppDir puts runfiles at <pkg>/<binary>.runfiles/, not AppRun.runfiles/. We'd need an AppRun.runfiles symlink or a layout change.
6. 32-bit arch coverage — Linux templates exist only for x86_64, aarch64, s390x. Our i386 and armv7e-m (armhf) runtimes in deps.bzl would have no launcher; we'd need upstream templates or keep the .sh AppRun as a fallback for those arches.
7. Embedded-arg limits — max 10 embedded args of ≤256 bytes each; an entrypoint rlocation path >256 bytes (deep package + long repo name) would hard-fail.
8. WORKSPACE users — hermetic-launcher is bzlmod/BCR-oriented; legacy WORKSPACE setups would need extra wiring.