Mathieu Benoit
9c470f065e
The catalogue only offered openSUSE Tumbleweed, a rolling release with no version number. Nearly every openSUSE incident in this series came from that: the cloud image is a snapshot lagging behind its own repos, hence the mandatory "zypper dup", and two VMs deployed the same day saw git-daemon 2.54 on s390x against 2.55 on amd64. For an ERP platform, that is not what should be offered by default. Leap 16.0 is numbered, stable, and publishes the three architectures that matter -- verified, x86_64, aarch64 and s390x all 200. It also unifies its tree: no separate /ports/, unlike Tumbleweed, whose equivalent paths 404 for Leap. Tumbleweed stays on offer, as a bellwether for breakage to come. Two things separate them in the scripts: the repository path, and "dup" -- which on Leap means CHANGING version, not updating. --- FR --- Le catalogue n'offrait qu'openSUSE Tumbleweed, une rolling sans numéro de version. Presque tous les incidents openSUSE de la série venaient de là : l'image cloud est un instantané en retard sur ses dépôts, d'où le « zypper dup » obligatoire, et deux VM déployées le même jour ont vu git-daemon 2.54 sur s390x contre 2.55 sur amd64. Pour une plateforme ERP, ce n'est pas ce qu'on veut proposer par défaut. Leap 16.0 est numérotée, stable, et publie les trois architectures qui comptent — vérifié, x86_64, aarch64 et s390x en 200. Elle unifie de plus son arbre : pas de /ports/ séparé, contrairement à Tumbleweed, dont les chemins équivalents rendent 404 pour Leap. Tumbleweed reste offerte, comme banc d'essai des ruptures à venir. Deux points les séparent dans les scripts : le chemin des dépôts, et « dup » — qui sur Leap sert à CHANGER de version, pas à mettre à jour. Assisted-by: Claude Opus 5
1.7 KiB
Déploiement
- Docker :
docker-compose.yml(PostgreSQL 18 + PostGIS 3.6) - Systemd :
script/systemd/pour les services - Nginx :
script/nginx/pour le reverse proxy - SSL : Certbot pour les certificats
- DNS :
script/deployment/update_dns_cloudflare.py
Plateformes supportées : Ubuntu 24.04 / 25.10 / 26.04, Linux Mint 22.3, Debian 12, AlmaLinux 9+, Rocky Linux 9+, openSUSE Leap 16 et Tumbleweed, Arch Linux, macOS (mise ou pyenv), Windows (WSL/Docker).
Ubuntu 20.04 et 22.04 sont abandonnées : pikepdf exige qpdf >= 12.2, compilé en C++20, quand focal livre GCC 9.
Interpréteur Python
EL_PYTHON_PROVIDER (dans env_var.sh) vaut auto, mise ou pyenv.
auto reprend un interpréteur DÉJÀ posé, quel que soit le fournisseur ; sinon
il préfère mise, qui pose un CPython précompilé, et retombe sur pyenv, qui le
compile.
Un seul fichier décide : script/install/lib_python_provider.sh. mise n'est
jamais installé automatiquement — make install_mise porte cette décision.
Pas de binaire mise pour s390x à ce jour : cette architecture reste sur pyenv.
Paquets Python
EL_PIP_PROVIDER (dans env_var.sh) vaut auto, uv ou pip. auto prend
uv s'il est présent et si le venv visé est en Python ≥ 3.8, sinon pip ; un
échec d'uv retombe sur pip. Un seul fichier décide :
script/install/lib_pip_provider.sh. uv n'est jamais installé
automatiquement — make install_uv porte cette décision.
Portée réelle : le venv d'outils et l'amorçage de Poetry. poetry install
n'est pas concerné — uv ne lit pas poetry.lock — et c'est pourtant l'étape
qui domine. Sur s390x le gain est quasi nul : une trentaine de paquets sans
roue se compilent, et uv n'enlève pas une seconde de gcc.