Version 2.8.29 / Lizenzserver 2.8.5: Release-Upgrade von Ubuntu bricht den venv nicht mehr

deploy/install.sh

@@ -418,9 +418,32 @@ info "Dateien abgeglichen (Instanzdaten unter data/ bleiben unangetastet)"
 
 # -- venv --------------------------------------------------------------------
 step "Python-Umgebung"
-if [[ ! -x "$ROOT/venv/bin/python3" ]]; then
+# Ein venv haengt an der **Minor-Fassung**, mit der er gebaut wurde: die Pakete
+# liegen unter lib/python3.X. Wechselt die Systemfassung -- ein Release-Upgrade
+# von Ubuntu bringt genau das, 24.04 hat 3.12 und 26.04 hat 3.14 --, dann ist
+# venv/bin/python3 weiter ausfuehrbar: der Verweis zeigt auf /usr/bin/python3,
+# also auf den **neuen** Interpreter. Der venv sieht heil aus und ist es nicht.
+# Er findet danach kein einziges Paket mehr, nicht einmal pip.
+#
+# Gemessen auf dem Testserver, mit verschobenem lib-Verzeichnis:
+#     [[ -x venv/bin/python3 ]]        -> wahr
+#     venv/bin/python3 -m pip --version -> "No module named pip"
+#
+# Die alte Pruefung fragte nur nach der Ausfuehrbarkeit. Sie haette den toten
+# venv behalten und waere eine Zeile spaeter an "python3 -m pip" gescheitert --
+# mitten in einer Aktualisierung, auf einem Server, dessen Dienste ohnehin
+# schon stehen. Gefragt wird deshalb, was gebraucht wird: laesst sich in
+# diesem venv pip benutzen?
+venv_traegt() {
+  [[ -x "$ROOT/venv/bin/python3" ]] || return 1
+  "$ROOT/venv/bin/python3" -c "import pip" >/dev/null 2>&1
+}
+if ! venv_traegt; then
+  # Ohne --clear: ein erneutes "venv" ergaenzt das fehlende lib-Verzeichnis und
+  # holt pip zurueck; die Abhaengigkeiten kommen gleich darunter ohnehin neu.
+  # Auch das ist gemessen und nicht angenommen.
   python3 -m venv "$ROOT/venv"
-  info "venv erzeugt"
+  info "Python-Umgebung aufgebaut ($(python3 -V 2>&1))"
 fi
 # Immer ueber "python3 -m pip" -- der pip-Shim im venv baeckt einen absoluten
 # Pfad in seinen Shebang, der nach einer Umbenennung des Verzeichnisses bricht.