[fli4l] Remoteupda?==?utf-8?Q?te der Recovery-Version

[Martin Dresbach]

Hallo Christoph!

Mir ist durchaus bewusst, dass der ursprüngliche Gadanke hinter der
Recovery-Funktion ein anderer war, als der für was ich es benutze.

Da dieser Mechanismus jedoch zuverlässig funktioniert (wie ich finde),
sehe ich auch keinen Grund, diesen nicht zu nutzen. Dem Fli ist es ja
letztendlich egal, aus welchem tatsächlichen Grund nun die alternative
(bzw. Recovery) Version gebootet werden soll.
Leider ist dies momentan für meinen Einsatzzweck die einzige
Möglichkeit, einen automatiesierten Ablauf zu realisieren.

Und sind wir doch mal ganz ehrlich: Wer würde denn bitte das Rad neu
erfinden? Es existiert bereits genau der Mechanismus um alternative
Configs / Setups zu nutzen, nur heißt dieser nun mal "opt_recover" und
nicht "opt_multiconfig". Ganz davon abgesehen gibt es ja dank dem
Entwickler des Paketes sogar die (undokumentierte) Funktion, eine dritte
Config zum Testen einzubinden. und mit etwas Schreibarbeit wären
durchaus auch mehr als 3 Configs möglich.

Allerdings würde mich mal interessieren, was aus rein technischer (bzw.
deiner) Sicht wirklich gegen meinen Anwendungsfall spricht. Immerhin ist
ja auch eine Recovery-Version nur eine alternative Config welche im
Bedarfsfall (bzw. Fehlerfall) gebootet wird.

Ich hatte es übrigens zuvor nicht erwähnt, aber ich betreibe dieses
Setup auf einem 3.10.7. Ein Feature-Request würde also sicherlich nie
zur Umsetzung kommen. Jedenfalls nicht für den 3er-Zweig.

Das klang jetzt vielleicht alles ein wenig hart, ist aber nicht so
gemeint! Du weißt doch, dass ich immer für deine Kritik und Hilfe
offen und dankbar bin! :)

Liebe Grüße,
Martin