[FIX] install s390x : pyproj exige le binaire proj, pas ses en-tetes

openSUSE eclate PROJ en trois paquets — libproj25 la bibliotheque,
proj-devel les en-tetes, proj les outils. Seul proj-devel etait pose, et
il ne tire PAS le troisieme.

pyproj n'a pas de roue s390x : il compile, et sa configuration execute
« proj » pour localiser l'installation. D'ou l'arret sur « proj
executable not found. Please set the PROJ_DIR variable », en plein
milieu d'un poetry install, sans que rien n'ait manque plus tot.

apt nommait deja proj-bin. dnf s'en remettait a une arete transitive :
elle tient sur RHEL, elle manque sur openSUSE. On la nomme donc partout
plutot que d'en dependre.

--- EN ---

openSUSE splits PROJ into three packages — libproj25 the library,
proj-devel the headers, proj the tools. Only proj-devel was installed,
and it does NOT pull the third.

pyproj has no s390x wheel: it builds, and its configuration runs "proj"
to locate the installation. Hence the stop on "proj executable not
found. Please set the PROJ_DIR variable", mid poetry install, with
nothing missing earlier.

apt already named proj-bin. dnf relied on a transitive edge: it holds on
RHEL, it is absent on openSUSE. So we name it everywhere rather than
depend on it.

Assisted-by: Claude Opus 5
(cherry picked from commit c02805a42eebf23380762ff6fc56db0aec1680b5)

script/install/install_fedora_dependency.sh

@@ -115,9 +115,16 @@ if [ "$(uname -m)" = "s390x" ]; then
   # roues masquent le besoin ; ici tout compile, et bcrypt s'arrête net sur
   # « error: can't find Rust compiler ». Les versions livrées suffisent
   # (AlmaLinux 1.92, Fedora plus récent) au Cargo.lock v4 qui exige 1.78.
+  # « proj » nommé À CÔTÉ de « proj-devel » : pyproj n'a pas de roue s390x, il
+  # compile, et sa configuration EXÉCUTE le binaire « proj » pour localiser
+  # l'installation — les en-têtes seules ne suffisent pas. Ici le paquet
+  # principal porte /usr/bin/proj et « proj-devel » l'exige, donc l'arriver
+  # transitivement fonctionnerait ; on le nomme quand même, comme apt le fait
+  # avec « proj-bin », parce que openSUSE a prouvé que cette arête n'existe pas
+  # partout — elle y manque, et l'échec n'apparaît qu'au build.
   ${DNF} \
     rust cargo \
-    libjpeg-turbo-devel zlib-devel geos-devel proj-devel \
+    libjpeg-turbo-devel zlib-devel geos-devel proj proj-devel \
     krb5-devel tbb-devel ninja-build clang-devel llvm-devel \
     GeographicLib-devel pkgconf-pkg-config cmake
 

script/install/install_suse_dependency.sh

@@ -262,8 +262,17 @@ if [ "$(uname -m)" = "s390x" ]; then
   #
   # GeographicLib est absent : openSUSE n'empaquette que le binding Python,
   # pas la bibliothèque C++. Rien à poser, contrairement à apt et dnf.
+  #   proj        le BINAIRE, pas seulement « proj-devel ». openSUSE éclate
+  #               PROJ en trois paquets : libproj25 la bibliothèque, proj-devel
+  #               les en-têtes, proj les outils en ligne de commande. pyproj ne
+  #               se contente pas des en-têtes — il EXÉCUTE « proj » pour
+  #               localiser l'installation, et sans lui s'arrête sur « proj
+  #               executable not found. Please set the PROJ_DIR variable ».
+  #               proj-devel ne le tire pas : la dépendance manque en silence
+  #               jusqu'au build, et aucune roue s390x ne vient l'éviter.
   zyp_soft qpdf-devel libjpeg8-devel cmake pkgconf-pkg-config \
-    tbb-devel geos-devel proj-devel krb5-devel ninja clang-devel llvm-devel
+    tbb-devel geos-devel proj proj-devel krb5-devel ninja clang-devel \
+    llvm-devel
   # Tumbleweed livre qpdf 12.3.2 : l'appel ne fait que le constater. Il est là
   # pour que les trois familles suivent la même règle.
   el_qpdf_ensure