Ce recalage était juste, et pour la bonne raison : le paquet Alpine vise la disposition d'Alpine, l'image officielle compile le serveur dans /usr/local.
⚠ Mais la branche Alpine a bougé. Mesuré le 2026-08-10 dans un conteneur jetable postgres:16-alpine, arm64 :
postgresql16 n'existe plus. La branche alpine 3.23 compile postgis contre PostgreSQL 18, quand l'image en porte 16.13.
La conséquence, et son calendrier
La production tourne encore : PostGIS y a été posé le 2026-08-08 et vit dans la couche inscriptible du conteneur actuel. Rien ne casse aujourd'hui.
Mais la tâche d'installation est justement conçue pour être rejouée après chaque déploiement compose, parce que recréer le conteneur efface PostGIS (c'est écrit dans group_vars/postgres/postgres.yml, et c'est exact). Donc :
conteneur recréé + rejeu du playbook → le cp -r échoue, la source n'existe pas.
C'est un échec bruyant, ce qui est le bon comportement — mais il tombera au pire moment : juste après une recréation de conteneur, avec une base qui a gardé ses colonnes géométriques et plus d'extension pour les lire.
⚠ Et surtout : ne pas « réparer » en pointant source_partagee sur postgresql18. Ça déplacerait des .so compilés pour un autre majeur, que le serveur 16 refuserait de charger. Le défaut se déplacerait de « fichier absent au rejeu » (visible) vers « extension présente mais inutilisable » (invisible jusqu'à la première requête spatiale). Les deux moitiés ne parlent plus du même PostgreSQL : aucun chemin ne répare ça.
La route qui marche, déjà mesurée ailleurs
kadans-api avait le même besoin pour son PostgreSQL de CI et a dû trancher : image Debian postgres:16 + postgresql-16-postgis-3 du dépôt PGDG, que l'image officielle Debian a déjà configuré. PGDG publie un paquet par majeur, donc l'alignement est structurel, et les fichiers atterrissent directement dans pg_config --sharedir — aucune copie, donc aucune occasion de se tromper de chemin.
Vérifié en arm64 : postgresql-16-postgis-3 3.6.4+dfsg-2.pgdg13+1, PostGIS_Version() → 3.6 USE_GEOS=1 USE_PROJ=1 USE_STATS=1, et la suite Go de kadans-api à l'exit 0 avec 0 saut. Voir ci/postgres-postgis/README.md de kadans-api PR 111.
Pistes, à arbitrer
Passer le Postgres du homelab sur l'image Debian postgres:16 et installer postgresql-16-postgis-3 — aligne prod et CI sur la même façon de poser PostGIS, ce qui est la condition pour que la CI prouve quelque chose sur la prod. Changement d'image de base : pas anodin pour une base qui porte des données.
Rester en Alpine et épingler la source sur une branche Alpine dont le postgis cible encore PG 16 — repousse le problème et le fera revenir.
Garder Alpine mais rendre l'échec explicite AVANT le cp : une tâche qui vérifie que /usr/share/postgresql$MAJ existe pour le majeur RÉEL du serveur, avec le message qui nomme la cause. Ne répare rien, mais transforme un cp cryptique en diagnostic.
Le point 3 est bon dans tous les cas ; le vrai arbitrage est entre 1 et 2.
Contexte
Ouverte depuis le passage kadans-api PR 111 / kadans-dossier PR 91 (ADR-0028). Rien n'a été modifié dans ce dépôt : la mesure y a été faite, la décision vous revient.
## Ce qui a changé sous le playbook
`setup/postgres.yml` (PR 52, commit `f944fe4`, 2026-08-08) installe PostGIS dans le conteneur Postgres puis **recale les chemins** :
```yaml
source_partagee: /usr/share/postgresql16/extension
source_lib: /usr/lib/postgresql16
```
Ce recalage était juste, et pour la bonne raison : le paquet Alpine vise la disposition d'Alpine, l'image officielle compile le serveur dans `/usr/local`.
⚠ **Mais la branche Alpine a bougé.** Mesuré le 2026-08-10 dans un conteneur jetable `postgres:16-alpine`, arm64 :
```
/etc/alpine-release → 3.23.4
apk info postgis → postgis-3.6.1-r0
pg_config --version → PostgreSQL 16.13
pg_config --sharedir → /usr/local/share/postgresql
find / -name "postgis*.control"
→ /usr/share/postgresql18/extension/postgis.control
find / -name "postgis*.so"
→ /usr/lib/postgresql18/postgis-3.so
ls -d /usr/share/postgresql* /usr/lib/postgresql*
→ /usr/lib/postgresql18 /usr/share/postgresql /usr/share/postgresql18
```
**`postgresql16` n'existe plus.** La branche alpine 3.23 compile `postgis` contre **PostgreSQL 18**, quand l'image en porte **16.13**.
## La conséquence, et son calendrier
La production **tourne encore** : PostGIS y a été posé le 2026-08-08 et vit dans la couche inscriptible du conteneur actuel. Rien ne casse aujourd'hui.
Mais la tâche d'installation est justement conçue pour être **rejouée après chaque déploiement compose**, parce que recréer le conteneur efface PostGIS (c'est écrit dans `group_vars/postgres/postgres.yml`, et c'est exact). Donc :
**conteneur recréé + rejeu du playbook → le `cp -r` échoue, la source n'existe pas.**
C'est un échec **bruyant**, ce qui est le bon comportement — mais il tombera au pire moment : juste après une recréation de conteneur, avec une base qui a gardé ses colonnes géométriques et plus d'extension pour les lire.
⚠ Et surtout : **ne pas « réparer » en pointant `source_partagee` sur `postgresql18`.** Ça déplacerait des `.so` compilés pour un autre majeur, que le serveur 16 refuserait de charger. Le défaut se déplacerait de « fichier absent au rejeu » (visible) vers « extension présente mais inutilisable » (invisible jusqu'à la première requête spatiale). Les deux moitiés ne parlent plus du même PostgreSQL : aucun chemin ne répare ça.
## La route qui marche, déjà mesurée ailleurs
`kadans-api` avait le même besoin pour son PostgreSQL de CI et a dû trancher : image Debian `postgres:16` + **`postgresql-16-postgis-3` du dépôt PGDG**, que l'image officielle Debian a déjà configuré. PGDG publie un paquet **par majeur**, donc l'alignement est structurel, et les fichiers atterrissent directement dans `pg_config --sharedir` — **aucune copie**, donc aucune occasion de se tromper de chemin.
Vérifié en arm64 : `postgresql-16-postgis-3` 3.6.4+dfsg-2.pgdg13+1, `PostGIS_Version()` → `3.6 USE_GEOS=1 USE_PROJ=1 USE_STATS=1`, et la suite Go de kadans-api à l'exit 0 avec 0 saut. Voir `ci/postgres-postgis/README.md` de **kadans-api PR 111**.
## Pistes, à arbitrer
1. **Passer le Postgres du homelab sur l'image Debian `postgres:16`** et installer `postgresql-16-postgis-3` — aligne prod et CI sur la même façon de poser PostGIS, ce qui est la condition pour que la CI prouve quelque chose sur la prod. Changement d'image de base : pas anodin pour une base qui porte des données.
2. **Rester en Alpine et épingler la source** sur une branche Alpine dont le `postgis` cible encore PG 16 — repousse le problème et le fera revenir.
3. **Garder Alpine mais rendre l'échec explicite AVANT le `cp`** : une tâche qui vérifie que `/usr/share/postgresql$MAJ` existe pour le majeur RÉEL du serveur, avec le message qui nomme la cause. Ne répare rien, mais transforme un `cp` cryptique en diagnostic.
Le point 3 est bon dans tous les cas ; le vrai arbitrage est entre 1 et 2.
## Contexte
Ouverte depuis le passage `kadans-api` PR 111 / `kadans-dossier` PR 91 (ADR-0028). Rien n'a été modifié dans ce dépôt : la mesure y a été faite, la décision vous revient.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Ce qui a changé sous le playbook
setup/postgres.yml(PR 52, commitf944fe4, 2026-08-08) installe PostGIS dans le conteneur Postgres puis recale les chemins :Ce recalage était juste, et pour la bonne raison : le paquet Alpine vise la disposition d'Alpine, l'image officielle compile le serveur dans
/usr/local.⚠ Mais la branche Alpine a bougé. Mesuré le 2026-08-10 dans un conteneur jetable
postgres:16-alpine, arm64 :postgresql16n'existe plus. La branche alpine 3.23 compilepostgiscontre PostgreSQL 18, quand l'image en porte 16.13.La conséquence, et son calendrier
La production tourne encore : PostGIS y a été posé le 2026-08-08 et vit dans la couche inscriptible du conteneur actuel. Rien ne casse aujourd'hui.
Mais la tâche d'installation est justement conçue pour être rejouée après chaque déploiement compose, parce que recréer le conteneur efface PostGIS (c'est écrit dans
group_vars/postgres/postgres.yml, et c'est exact). Donc :conteneur recréé + rejeu du playbook → le
cp -réchoue, la source n'existe pas.C'est un échec bruyant, ce qui est le bon comportement — mais il tombera au pire moment : juste après une recréation de conteneur, avec une base qui a gardé ses colonnes géométriques et plus d'extension pour les lire.
⚠ Et surtout : ne pas « réparer » en pointant
source_partageesurpostgresql18. Ça déplacerait des.socompilés pour un autre majeur, que le serveur 16 refuserait de charger. Le défaut se déplacerait de « fichier absent au rejeu » (visible) vers « extension présente mais inutilisable » (invisible jusqu'à la première requête spatiale). Les deux moitiés ne parlent plus du même PostgreSQL : aucun chemin ne répare ça.La route qui marche, déjà mesurée ailleurs
kadans-apiavait le même besoin pour son PostgreSQL de CI et a dû trancher : image Debianpostgres:16+postgresql-16-postgis-3du dépôt PGDG, que l'image officielle Debian a déjà configuré. PGDG publie un paquet par majeur, donc l'alignement est structurel, et les fichiers atterrissent directement danspg_config --sharedir— aucune copie, donc aucune occasion de se tromper de chemin.Vérifié en arm64 :
postgresql-16-postgis-33.6.4+dfsg-2.pgdg13+1,PostGIS_Version()→3.6 USE_GEOS=1 USE_PROJ=1 USE_STATS=1, et la suite Go de kadans-api à l'exit 0 avec 0 saut. Voirci/postgres-postgis/README.mdde kadans-api PR 111.Pistes, à arbitrer
postgres:16et installerpostgresql-16-postgis-3— aligne prod et CI sur la même façon de poser PostGIS, ce qui est la condition pour que la CI prouve quelque chose sur la prod. Changement d'image de base : pas anodin pour une base qui porte des données.postgiscible encore PG 16 — repousse le problème et le fera revenir.cp: une tâche qui vérifie que/usr/share/postgresql$MAJexiste pour le majeur RÉEL du serveur, avec le message qui nomme la cause. Ne répare rien, mais transforme uncpcryptique en diagnostic.Le point 3 est bon dans tous les cas ; le vrai arbitrage est entre 1 et 2.
Contexte
Ouverte depuis le passage
kadans-apiPR 111 /kadans-dossierPR 91 (ADR-0028). Rien n'a été modifié dans ce dépôt : la mesure y a été faite, la décision vous revient.