Derzeit wird ein Update immer noch mit dem alten Updater ausgeführt, weshalb es kritisch und schwierig ist, Änderungen am Updater durchzuführen und zu testen: Fehler im aktuellen Updater fallen ggf. es viel später dann beim nächsten Update auf. Von daher sollte überlegt werden, ob der Updater nicht als erstes beim Updaten aktualisiert wird und der Rest dann mit dem neuen Updater installiert wird. Das würde auch Bug #14537 erübrigen, da dann so auch aktualisierte {pre,post}up.sh Skripte im selben Paket mitverteilt werden können. Problematisch kann sein, daß der Updater dann sowohl in der alten, als auch in der neuen UCS-Version mit ggf. unterschiedliche Versionen von libc, Python, pysupport, pycentral funktionieren muß. Dies ließe sich durch ggf. eine interrim-Version umgehen: Beim Update von 2.x-y wird erst der Updater aus 2.x-(y') installiert, um dann anschließend erst damit auf 2.(x+1)-0 oder 3.0-0 zu aktualisieren. Diese Funktionalität kann ggf. mit dem preup.sh Skript zusammenspielen: 1. in preup.sh feststellen, das der aktuelle updater auszutauschen ist, 2. neuen Updater herunterladen und installieren, 3. per exit-Code oder andere Möglichkeit dem alten Updater signalisieren, sich durch den neuen Updater zu ersetzen (Python-Äquivalent zum Shell-Aufruf 'exec "$0" "$@"') Anmerkungen: 1. Erst seit der Behebung von Bug #16454 (UCS_2.3-1) wird der Return-Code auch von u-updater richtig ausgewertet, so daß preup.sh-Skripte ab nun den u-updater im Fehlerfall nicht länger per "kill" beenden müssen.
Ich setze den erstmal auf 2.x. Je nach verfügbarer Zeit sollten wir den Bug für 2.3-x oder 2.4 vorsehen.
This issue has been filed against UCS 2.3. UCS 2.3 is out of maintenance and many UCS components have vastly changed in later releases. Thus, this issue is now being closed. If this issue still occurs in newer UCS versions, please use "Clone this bug". In this case please provide detailed information on how this issue is affecting you.