Build development release on trixie/sid for Debian

[waterkip]

This could potentially uncover issues because sid and by extension trixie are development releases of the Debian project. They for example undergo t64 migrations, get newer compilers and this potentially uncovers more information when running development releases. For example, see gcc:

apt-cache policy gcc
gcc:
Installed: 4:14.1.0-2
Candidate: 4:14.1.0-2
Version table:
*** 4:14.1.0-2 900
900 https://deb.debian.org/debian unstable/main amd64 Packages
500 https://deb.debian.org/debian testing/main amd64 Packages
100 /var/lib/dpkg/status
4:12.2.0-3 10
10 https://deb.debian.org/debian stable/main amd64 Packages
4:10.2.1-1 10
10 https://deb.debian.org/debian oldstable/main amd64 Packages
4:8.3.0-1 10
10 https://deb.debian.org/debian oldoldstable/main amd64 Packages

[waterkip]

The reason why I'm adding this is that I ran into the following bug on my Debian Sid install and didn't have the issue at Debian Bookworm: net-amqp-rabbitmq/net-amqp-rabbitmq#252

[zakame]

Hi @waterkip, thanks for the PR!

I can relate to this (having been a Debian maintainer once) so I think this is good 👍 OTOH we don't have a precedent in docker-library/official-images for providing testing/sid images for language containers (aside from buildpack-deps and debian itself,) only stable/oldstable AFAIK - can @tianon chime in? 🙏

[tianon]

We typically actively discourage it, especially because it'll be prone to periodic breakage for things like transitions in the upstream distribution. 🙈

A reasonable middle ground might be to generate the Dockerfiles, but not build/publish images of them by default, like we did for the EOL releases 🤔 Then it's easy for users who need it to build for themselves, but we don't burden the build system with a lot of extra potentially unstable builds 😅

[waterkip]

Alternatively, we can build against Ubuntu? 24.10 show cases the same bug.