2 Commits

Include renames

Author	SHA1	Message	Date
maggesandClaude Sonnet 5	18b414d7b5	Fix build: podman-compose.SlackBuild was missing its executable bit ... Every other packages/*/*.SlackBuild is 755 — this one was created at 644 (likely from how it was originally written to disk), so scripts/build-packages.sh's own executability check correctly refused to run it ("No SlackBuild found/executable for 'podman-compose'"), failing the whole build — confirmed from a real Gitea Actions run's log (build-packages.yml run 110). Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-07-12 21:40:58 +00:00
maggesandClaude Sonnet 5	2b79411b68	Replace vendored docker-compose with podman-compose ... podman-compose and docker-compose aren't discovered the same way by `podman compose` - verified live (a fake-binary test reading podman's own provider-search error output) that docker-compose is searched for by exact path across a fixed list of CLI-plugin directories, while podman-compose is instead looked up as a plain command on $PATH. This package installs to /usr/local/bin/podman-compose accordingly, not under any cli-plugins/ directory. Unlike docker-compose (a single static Go binary), podman-compose is a Python script with two runtime dependencies neither of which ship with Unraid's own Python3 - PyYAML and python-dotenv, vendored here as plain pure-Python source (no C extension build; PyYAML's own fallback handles its optional C accelerator being absent). Verified end-to-end on a real host: with the previous docker-compose binary temporarily moved aside to confirm podman-compose was actually the one invoked, `podman compose up/ps/down` ran a real compose project correctly, including a live HTTP check against the started service. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-07-12 18:35:38 +00:00