missing dependency when ran on Docker debian:trixie-slim image, missing suite: for 32bit and old raspbian-archive-keyring.gpg

[yyang-giatec]

Hello,

We did some testing building inside containers with debian:trixie-slim instead, so that the build can run on a broader range of OSes, and we would like to share some findings.

1. layer/raspbian/*/base-apt.yaml declares variant: apt with no suite

The suite: line is missing for 32-bit repos but present in the 64-bit ones. This causes mmdebstrap versions newer than a certain point (1.5.1?) to fail with I: nothing to extract -- skipping....

2. keydir/raspbian-archive-keyring.gpg uses only SHA-1; newer apt versions reject it

We replaced it with a current key obtained from raspbian-archive-keyring_20120528.4_all.deb.

3. Missing dependencies

The following packages were added to depends, although packages other than zlib1g-dev are probably pulled in automatically when --no-install-recommends is not used.

Item	Note
zlib1g-dev	erofs-utils's lib/gzran.c:9 has #include <zlib.h> above the #ifdef HAVE_ZLIB at line 11, and lib/Makefile.am:95 adds gzran.c unconditionally
xz-utils	package/util-linux/util-linux-2.41.3.meta fetches a .tar.xz; util-linux is a PKG_DEPS of erofs-utils (package/erofs-utils/Makefile:4)
ca-certificates	bin/vfetch:134 fetches tarballs with curl --fail --location over https://
file	layer/base/deploy.sh:67: mime_type=$(file -b --mime-type "$f" 2>/dev/null || echo "unknown")

[learmj]

Raspbian is community support driven: it's not supported by us and we are not responsible for its packages. I will look into the key situation. While Raspbian can be installed and run on current gen devices, I'm not sure why you'd really need/want to do that. It's fair to say that support of Raspbian in rpi-image-gen is best effort at the most. All current device layers are v8. Why not use armhf as a foreign arch and use Debian packages rather than Raspbian?

I don't understand the comments about erofs-utils or util-linux: rpi-image-gen builds those tools for the host itself. No packages from the host are used outside of those in the (private) mini sysroot (you can check the build.log).

I run builds in my own slim container every so often to check things: what actual problems did you encountered in your environment?

Thanks for your report.

[yyang-giatec]

Thanks!

Regarding to zlib1g-dev I have checked that again. This was due to our use of --no-install-recommends in wrapper script in attempt to speed up building on fresh instance or resource/performance constrained machine.

Minimal example to reproduce on v2.8.0 WSL2/ubuntu 24.04 x64 is attached below, zlib1g-dev would not be present afterwards hence not available for host either. For xz-utils/ca-certificates/file they weren't explicitly specified but got pulled in anyway so we added them just in case.

diff --git a/lib/dependencies.sh b/lib/dependencies.sh
index 5052bf6..fda0708 100644
--- a/lib/dependencies.sh
+++ b/lib/dependencies.sh
@@ -86,7 +86,7 @@ dependencies_check()
       echo

       if (( install_mode )); then
-         apt install -y "${unique[@]}"
+         apt install -y --no-install-recommends "${unique[@]}"
       else
          exit 1
       fi

podman run --rm -it \
  --privileged --security-opt label=disable \
  -v "$PWD:$PWD" -w "$PWD" \
  -e DEBIAN_FRONTEND=noninteractive -e LANG=C.UTF-8 -e LC_ALL=C.UTF-8 \
  docker.io/library/debian:trixie-slim bash

apt-get update 
./install_deps.sh

root@ee1c84d9732b:/rpi-image-gen# dpkg -l | grep -E '^ii[[:space:]]+(zlib1g-dev|xz-utils|ca-certificates|file)(:[^[:space:]]+)?[[:space:]]'
ii  ca-certificates                   20250419                             all          Common CA certificates
ii  file                              1:5.46-5                             amd64        Recognize the type of data in a file using "magic" numbers
ii  xz-utils                          5.8.1-1+deb13u1                      amd64        XZ-format compression utilities
root@ee1c84d9732b:/rpi-image-gen#

[learmj]

Hi. When I read your initial report last night, the rendering of the table was missing some context, hence my reply.

Regarding to zlib1g-dev I have checked that again. This was due to our use of --no-install-recommends in wrapper script in attempt to speed up building on fresh instance or resource/performance constrained machine.

This sounds like a bug in erofs-utils to me. I already submitted one fix there which sounds a lot like your issue, see below:

See erofs/erofs-utils@cade811

I will look into that again.

I can see why the others might be needed. My own 'slim' container image wasn't from Debian, but it was very minimal.
Thanks again for the report. I'll post back here when I've got some findings.