Build `standard` and `system` images for PostGIS 3.5

[gbartolini]

Description

Now that the postgres-containers project has been permanently decoupled from the official Docker PostgreSQL image and we are building and maintaining our own images, we can leverage them to produce PostGIS-enabled images.

The goal is to support PostGIS until PostgreSQL 17 is phased out (November 2029). Starting with PostgreSQL 18, all supported versions will include the extension_control_path GUC, allowing PostGIS to be mounted as a separate image volume, making dedicated PostGIS images unnecessary.

Scope

We should build PostGIS images on top of the following base images:

• standard (without Barman Cloud)
• system (with Barman Cloud)

Support should follow the upstream PostgreSQL and Debian lifecycle, aligned with the postgres-containers images.

Proposal

Start with a pilot project to validate feasibility. Reuse everything possible from the postgres-containers project. If successful, we can extend and promote the solution as the official way to build PostGIS for CloudNativePG, and transition from the current system.

Example

Suppose the last available standard PostgreSQL 16 image on trixie is:

postgresql:16.10-202509090953-standard-trixie

We should build the corresponding PostGIS image with the tag:

postgis:16.10-3.5.3-${TS}-standard-trixie

Where ${TS} is the build timestamp of the PostGIS image (which must be later than 202509090953).

This should also produce the following rolling tags:

postgis:16.10-3.5.3-standard-trixie
postgis:16-3.5-standard-trixie

[mnencia]

The new system should not build any Bullseye-based images.

Since May 2025, packages for Bullseye have not been built because they fail the regression tests.

Ref: https://salsa.debian.org/postgresql/apt.postgresql.org/-/commit/c12cb5e5b2662172317363159fb5731da2c98957

[gbartolini]

I think it makes sense to remove bullseye from the matrix of builds for PostGIS. It also reflects our "best-effort" policy adopted in the postgres-containers project. I would like to hear more, but before we merge this patch (or with a subsequent one), we should rewrite the README and provide clear guidance on what we do and support.

[elagree]

The new system should not build any Bullseye-based images.

Since May 2025, packages for Bullseye have not been built because they fail the regression tests.

Ref: https://salsa.debian.org/postgresql/apt.postgresql.org/-/commit/c12cb5e5b2662172317363159fb5731da2c98957

I can understand your point but as you postgis-containers was provided on top of docker-postgis image which used bullseye this is very annoying to change the underlying OS in a minor version.
People (like us) who are using postgis-containers will not be able to upgrade easily from Postgresql 17.5 to 17.6 smoothly.
According to other discussions changing the Debian version require additional steps which can require a logical replication which is trivial in production environment.