# packages/docker-compose/

Pinned version: see `DOCKER_COMPOSE_VERSION` in [versions.env](../../versions.env).

Not built from source — `docker-compose.SlackBuild` fetches and repackages
upstream's own prebuilt static x86_64 release binary (`docker/compose`,
the Go-based Compose v2 CLI plugin — a different project from the older
Python `podman-compose`). It's a small, purely static ELF with zero
runtime library dependencies (verified: `ldd` reports "not a dynamic
executable"), so there's nothing meaningful to gain from a from-source
build.

`podman compose` (backing the WebUI's Compose panel, see
`webui/plugins/podman/ajax/compose.php`) has no compose implementation of
its own — it shells out to an "external compose provider" it discovers by
searching a fixed list of CLI-plugin directories for a binary named
`docker-compose`. Without one present, every Compose panel action fails
outright. Installed to `/usr/local/lib/docker/cli-plugins/docker-compose`
— one of podman's own search paths (extracted from the pinned podman
binary: `strings /usr/bin/podman | grep cli-plugins`), chosen specifically
under `/usr/local/` rather than `/usr/lib/docker/...` so this package
never collides with (or gets silently shadowed by) a genuine Docker
installation's own compose plugin on hosts that also run Unraid's
built-in Docker support.

Found by live-testing the Compose panel end-to-end against a real Unraid
install: it happened to work only because that particular host already
had Docker's own `docker-compose` plugin installed from an unrelated,
pre-existing Docker setup — a clean Unraid install has no compose
provider at all without this package. See
[docs/ARCHITECTURE.md, section 5.1](../../docs/ARCHITECTURE.md#51-zu-paketierende-komponenten).