gui_bootmanager: add support for "fixed branding"-approach used in Freetz

Warum verfolgt Freetz hier überhaupt einen anderen Ansatz bei der Änderung?

Welcher Vorteil ergibt sich genau aus dem Vorgehen in Freetz?

Original:

##########################################################################################
## OEM Ermitteln
##########################################################################################
OEM_tmp=`cat $CONFIG_ENVIRONMENT_PATH/firmware_version`
if [ -z "${OEM_tmp}" ] ; then
OEM_tmp=$CONFIG_OEM_DEFAULT
fi
OEM=${OEM_tmp%,*}
OEM_DEFAULT_INDEX=${OEM_tmp#*,}
if [ "$OEM_DEFAULT_INDEX" = "$OEM" ] ; then
OEM_DEFAULT_INDEX=""
fi
export OEM_DEFAULT_INDEX
export OEM

Immer wenn ich im IPPF diesen Weg der Änderung des Brandings als Möglichkeit beschrieben habe:

https://www.ip-phone-forum.de/threads/7590-branding-%C3%A4ndern-freetz-flashen.298603/#post-2265245 https://www.ip-phone-forum.de/threads/fritzbox-6490-cable-bootloop.282765/page-7#post-2266798 https://www.ip-phone-forum.de/threads/anleitung-zum-%C3%84ndern-des-branding-bei-fritzbox-auch-f%C3%BCr-daus.203652/page-74#post-2238898 (um mal ein paar Beispiele zu benennen)

, dann habe ich (auch wegen der Eindeutigkeit der Fundstelle - weil es nur eine Zeile gibt, die ein export OEM enthält, denn die darüber zählt hier nicht wirklich, weil sie mit passendem Regex ausgeblendet werden kann: https://github.com/PeterPawn/modfs/blob/master/modscripts/mod_fixed_branding#L35) immer von dieser export OEM-Zeile geschrieben und daß diese in export OEM=<branding> geändert werden sollte.

In meinen Augen macht es die zusätzliche Behandlung in den folgenden Zeilen nur komplizierter, dem Flow zu folgen, wenn man die Ersetzung in der Zeile direkt nach den Kommentaren vornimmt, wie Du es dann in Freetz übernommen hast (was ich zuvor gar nicht gesehen hatte, zumindest nicht die tatsächliche Umsetzung).

In meiner E-Mail zu diesem Patch in Freetz schrieb ich auch noch an Dich:

_Solange eine Box zu denen gehört, wo das dauerhafte Überschreiben von firmware_version nicht möglich ist, finde ich den Weg mit der Änderung von export OEM besser, weil es eben keinen zusätzlichen Schreibzugriff gibt (der durchaus auch ausgeführt wird, nur interessiert das den Loader beim nächsten Start nicht) und die Box sich davon ja ohnehin nicht dauerhaft beeindrucken läßt._

_Ich hatte mich damals (als ich den Vorschlag machte) vergewissert, daß es in der Firmware keine anderen Stellen mit "firmwareversion" gab (grep über alles) und die einzige wirklich das Setzen von $OEM war ... was in der Folge dann überall abgefragt wird, weil es auch dafür eine Funktion in der "libboxlib.so" gibt (aus dem Kopf).

Der ganze andere Quatsch von AVM wird (wenn man es analysiert, was da gemacht wird) ohnehin nicht verarbeitet, wenn man in dieser Zeile nicht aus dem Environment liest, sondern ein einzelnes Branding (das dann auch keinen DEFAULT_INDEX hat, wenn man dem Patch in Freetz folgt) fest einträgt.

Theoretisch könnte man (wenn man die Änderung nicht so klein wie möglich halten will) sogar alle Zeilen vor den beiden export-Statements gleich komplett mit entsorgen.

Ich verstehe also nicht, warum die Änderung in Freetz an einer anderen Stelle erfolgt (vielleicht sehe ich ja auch den plausiblen Grund für eine solche Entscheidung nicht und Du kannst es begründen) und warum daraus jetzt noch eine Änderung am gui_bootmanager resultieren soll. Warum verwendet man in Freetz nicht einfach ebenfalls die Änderung der zweiten export-Zeile?

Zumal ich das eben (Begründung siehe oben) auch noch logischer und leichter zu verfolgen fände, weil man bei der Ansicht des export-Statements direkt erkennen kann, daß alles davor nur Makulatur war.

Wer die Zeilen davor dann zu kompliziert findet, wirft sie einfach gleich mit raus beim Patchen. In modfs verlege ich mich ja absichtlich - auch an anderen Stellen - auf die kleinsten möglichen Veränderungen der originalen Firmware und habe deshalb nicht die Absicht, das dort zu entfernen.

Na ja, die Logik ist eigentlich ganz primitiv:

Ersetze an der Stelle, an der das Branding aus dem Environment ausgelesen wird, das Auslesen durch einen fixen Wert.
Dann muss man sich mit den restlichen Zeilen erst gar nicht beschäftigen, i.e diese analysieren/nachvollziehen.
Dann ist auch man gegen die zukünftigen Anpassungen von AVM an der Stelle gewappnet (auch wenn diese vermutlich unwahrscheinlich sind). [Habe mit Absicht das Wort "gewappnet" verwendet und nicht "sicherer", damit nicht der Eindruck entsteht, dass damit ein Vergleich mit der in modfs umgesetzten Logik gemacht wird.]

Bei der in Freetz umgesetzten Logik handelt es sich auch um einen Einzeiler oder in deiner Sprache "die kleinste mögliche Veränderung der originalen Firmware" - das Auslesen wird durch einen fixen Wert ersetzt.

Ich habe nicht verlangt, dass modfs in irgendeine Weise angepasst wird (dein letzter Absatz). Ich habe lediglich einen Patch submittet, der den Bootmanager um die in Freetz verwendete Logik erweitert.

Meine - dagegen gesetzte - Logik ist es: Ändere die Stelle, wo etwas wirklich seine Auswirkungen zeitigt ... dann kann man den Rest auch weglassen (aber das habe ich oben ja schon versucht zu erläutern) und wenn jemand sich im Detail damit befassen will, was da tatsächlich geschieht (code review), sieht er es auf den ersten Blick und nicht erst nach der Analyse von neun weiteren Code-Zeilen.

Mein Änderungsvorschlag setzt bei den Auswirkungen an und Deine Implementierung in Freetz bei den "Eingabewerten" - die durch nachfolgende Verarbeitung und Umformung zumindest potentiell noch einer Veränderung unterworfen sein können und wo das Ergebnis des Patches somit von weiterem Code zwischen der geänderten Stelle und dem "Wirk-Statement" beeinflußt werden kann oder wenigstens könnte.

BTW ... ich habe auch nie behauptet, daß Du von mir eine Änderung in modfs fordern würdest (wo willst Du das denn gelesen haben?) - ich habe die Option aufgezeigt, die anderen Zeilen - mit Ausnahme der beiden export-Statements, denn das sind hier die wirklich entscheidenden - komplett zu entfernen, wenn deren Existenz jemanden verwirren sollte und man sie nach der Änderung der export OEM-Zeile als obsolet ansieht - damit ändert sich an der Erkennungslogik im gui_bootmanager auch nicht ein Deut und die export-Zeile selbst kann man nur deutlich schwieriger entfernen.

Meine Frage zielte ja deutlich auf den funktionellen Unterschied zwischen der meinerseits angesprochenen/vorgeschlagenen Implementierung (siehe meine E-Mail mit Datum: Thu, 23 Aug 2018 22:48:34 +0200) in der export OEM-Zeile und der schlußendlichen Umsetzung in Freetz.

Ich hatte die darauf folgende Änderung in Freetz zwar zur Kenntnis genommen, mich aber gar nicht in den modsed-Aufruf vertieft und damit auch nicht gesehen, daß in Freetz eben genau nicht das export OEM-Statement geändert wird.

Deine eigene Entscheidung ... aber ich habe in den gui_bootmanager die Behandlung dieser Option genau so eingebaut, wie es meinem Vorschlag (und der tauchte auch in der E-Mail an Dich nicht zum ersten Mal auf, wie die Beispiel-Links oben zeigen sollten) entsprach und gar nicht gesehen, daß Du diesen "abgeändert" hast.

Das Argument, daß man da ändert, wo es am deutlichsten und am leichtesten nachvollziehbar ist, wäre zu entkräften - i.V.m. dem optionalen Entfernen der dann ohnehin überflüssigen Zeilen.

Die korrekte Behandlung eines DEFAULT_OEM_INDEX (der in internationalen Versionen durchaus noch existieren könnte, wie ein Blick in die /etc/default.$Country-Verzeichnisse zeigt) fällt durch die Implementierung des Patches in Freetz (und den Vergleich mit einem Wert aus support_brandings()) ja ebenfalls flach ... ist also kein Argument für die frühzeitige Änderung.

Dabei muß man den AVM-Code dann schon noch anschauen, wenn man verstehen will, was da eigentlich passiert - wenn jetzt hier auf einmal Argumente in der Richtung:

Dann muss man sich mit den restlichen Zeilen erst gar nicht beschäftigen, i.e diese analysieren/nachvollziehen.

kommen, wo Du ansonsten immer damit argumentierst, daß mit so mancher "stilistischen Änderung" ein "review" dann (zumindest für Dich) leichter wäre als mit dem originalen Code irgendeines Autors, verblüfft mich das auch einigermaßen - warum auf einmal diese geänderte Haltung, daß das niemand ansehen und verstehen müsse?

Wenn Du also gute und nachvollziehbare Gründe dafür gehabt haben solltest, die Implementierung in Freetz eben gerade nicht durch die Änderung von export OEM umzusetzen, dann interessieren mich diese durchaus ... ein "gewappnet" gegen künftige Änderungen der letzten Zeile (EDIT: durch AVM) im oben gezeigten Ausschnitt kann ich nämlich nicht nachvollziehen - erst recht nicht, warum das bei einer Änderung der letzten Zeile durch den Patch nicht (oder mit geringerer Wahrscheinlichkeit) der Fall sein sollte.

Nur dann, wenn AVM die Variable irgendwie anders als OEM nennen sollte, wäre hier eine "Verbesserung" ggü. der Änderung des export-Statements wahrscheinlich ... Modifikationen an /proc/sys/urlader finden hingehen immer wieder mal statt (da könnte problemlos auch ein Auslesen direkt aus dem chosen-Zweig im FDT stehen), wie man u.a. an der Verschiebung von /proc/sys/urlader/config nach /proc/avm/calib (als m.W. jüngste Änderung an dieser Stelle, wo es um die Finalisierungsdaten geht) sehen kann (die Variable CONFIG_PATH_ENVIRONMENT existiert auch deshalb, weil dieser Wert für firmware_version früher schon über einen anderen Pfad als /proc/sys/urlader erreichbar war und schon einmal geändert wurde) und auch wenn Du nur auf firmware_version beim Ändern der Zeile testest, besteht eine deutlich höhere Chance, daß künftige Änderungen durch AVM eine weitere Zeile hinzufügen könnten, auf welche das Muster ^([ \t]*OEM_tmp=).*firmware_version.*$ zusätzlich paßt.

Das entscheidende Statement für das durch den Patch geänderte Verhalten der Firmware ist das export OEM, hier findet die eigentliche Änderung ggü. der originalen Version statt. Wenn sich also jemand den Patch ansieht und schaut, welche Zeile da geändert wird, landet er unmittelbar bei der richtigen - für mich eindeutig leichter nachzuvollziehen von einem Dritten, als wenn erst noch die Logik der anderen (derzeit neun) Zeilen davor zu erkunden wäre.

Die Wahrscheinlichkeit, daß AVM die OEM-Variable ändert, dürfte (aufgrund der erheblichen Auswirkungen in allen Teilen der Firmware) auch deutlich geringer sein, als die Wahrscheinlichkeit, daß AVM an der Logik beim Zusammenbasteln der zu exportierenden Werte etwas verändert ... nicht einmal der Variablenname OEM_tmp ist in Stein gemeißelt bzw. deutlich weniger fix, als der Name der zu exportierenden Variablen und für den Export einer Shell-Variablen in das Environment für die Kindsprozesse, gibt es lange nicht so viele Alternativen, wie für die vorhergehende Verarbeitung irgendwelcher Werte, die irgendwoher gelesen wurden.

Wenn AVM in den Zeilen vor dem export noch irgendwelche anderen Quellen auslesen möchte und das entsprechend ändert, funktioniert der Freetz-Patch nicht mehr wie erwartet ... weil er eben nicht die Stelle angreift, an der die "action" tatsächlich erfolgt. Im Unterschied zum Freetz-Patch kann man bei der Änderung der export OEM-Zeile die gesamte Verarbeitung davor auch entfernen (das entscheidet dann derjenige, der die Änderung ggf. von Hand vornimmt) - für mich ein weiterer Punkt, eben das export selbst zu ändern und nicht irgendetwas anderes davor.

Es ist sicherlich unverkennbar, daß ich noch nicht überzeugt bin und die Notwendigkeit des hier vorgeschlagenen Patches u.a. deshalb nicht erkennen kann, weil mir nicht klar wird, warum Du in Freetz genau diesen Weg der Änderung eingeschlagen hast - meine Argumente, warum ich diesen für weniger geeignet halte (ich verzichte ganz bewußt auf die Bewertung schlechter, weil ich ja auch den Standpunkt vertrete, daß es immer mehrere Wege einer Umsetzung gibt und jede ihre Vor- und Nachteile hat, die man eben gegeneinander abwägen muß), habe ich vorgetragen.

Es wäre jetzt an Dir, diese zu entkräften und zu zeigen, daß es eben nicht nur das "Andersmachen" war, was Dich hier bei Deinen Überlegungen im Vorfeld zu dieser Änderung geleitet hat.

Das Argument "ich ändere da, wo es ansonsten ausgelesen würde" habe ich zur Kenntnis genommen und ihm die potentielle Umformung des Wertes vor dem Export entgegengestellt, die mit höherer Wahrscheinlichkeit zu unerwünschten Effekten führen kann, als die Änderung direkt beim Export.

Die anderen zwei Punkte in Deiner Begründung (hier wäre es auch nett, wenn Du künftig gleich ein oder zwei Worte zu den Gründen für den Vorschlag verlieren könntest - das macht es nicht nur mir leichter, den Vorschlag einzuordnen, es hilft auch Dritten eher zu verstehen, worum es da überhaupt geht) kann ich nicht nachvollziehen.

Sorry, ich kann deinen Argumenten nicht folgen bzw. diese nicht nachvollziehen. Warum in aller Welt muss ich mich mit den Zeilen nach dem Auslesen aus dem Environment beschäftigen? Diese kann ich komplett ignorieren, es ist mir egal, was und wie AVM da macht - ich versuche sich nicht mal zu verstehen. Ob ich den Wert direkt ins Environment reinschreibe (auf den Boxen, auf denen es geht) oder beim Auslesen so tue, als würde genau der Wert drin stehen, ist doch genau das gleiche. Beim direkten Reinschreiben ins Environment habe ich mich mit diesen Zeilen doch nicht beschäftigen müssen, warum auf einmal jetzt? Entscheidend ist, dass alle Auslese-Stellen erwischt werden (das trifft zu, es gibt genau eine) und dass der verwendete fixe Wert ein sinnvoller Wert ist, einer, den ich (auf einer anderen Box, auf einer auf der es geht) direkt ins Environment reinschreiben könnte.

Auch deine Gegenargumentation gegen "gewappnet" kann ich nicht nachvollziehen. Es ist mir egal, was AVM nach dem Auslesen macht und wie die Änderungen an der Stelle ausschauen könnten - solange alle Auslese-Stellen erwischt sind und ein sinnvoller Wert als fixer Wert verwendet wird, kann nichts passieren, denn es ist das gleiche als würde dieser Wert in dem Environment stehen.

Am Ende sei gesagt, beide Lösungen haben ihre Dasein Berechtigungen. Ich fand "suggeriere es an der Auslese-Stelle" besser. Der kleine Vorteil meiner Lösung besteht darüberhinaus darin, dass man tatsächlich fixe Werte mit einem OEM_DEFAULT_INDEX setzen kann und diese auch korrekt verarbeitet werden. Dein Ansatz lässt dies nicht zu.

p.s. Ich finde es überraschend, wie viel Aufwand du ins "Schlecht-Reden" meines Ansatzes investierst. Wenn du den Pull-Request nicht übernehmen möchtest, kann ich damit leben. Du musst nicht viel argumentieren.

p.p.s. Den letzten Absatz aus Comment 1, konkret den allerletzten Satz von diesem "habe deshalb nicht die Absicht, das dort zu entfernen", habe ich so aufgefasst, als hättest du mich so verstanden, als würde ich dich (indirekt) zum Anpassen/zum Enrfernen deines Codes auffordern. Das "entfernen" bezieht sich jedoch vermutlich auf die "Zeilen" - dann habe ich dich missverstanden.

Ich verstehe nicht, warum es in Freetz überhaupt eine andere Lösung gibt für das Setzen eines festen "Brandings" und daher möchte ich diesen Pull-Request nicht übernehmen.

Wenn Du auf dem "Andersmachen" in Freetz beharren möchtest, dann kannst Du problemlos auch die Zeile aus diesem PR dazupatchen, wenn Du das tatsächlich als notwendig erachtest.

Daß mein Vorschlag sowohl in der E-Mail-Kommunikation mit Dir als auch in diversen Beiträgen im IPPF anders aussah (und zwar so, wie ihn der gui_bootmanager derzeit auswertet), ist sicherlich unstrittig - auch wenn das "modscript" für die Änderung in "modfs" erst nachträglich Einzug gehalten hat. Wenn Du Dich für eine davon abweichende Umsetzung entschieden hast, ist das Deine Sache.

Ich kann und werde aber bei weiteren Änderungen an diesem Skript keine Rücksicht auf diese Unterschiede nehmen, weil sie ohne jede Notwendigkeit und damit mutwilig hervorgerufen werden - das gilt dann auch für die Fehlersuche in dieser abgewandelten Version, so eine solche erforderlich werden sollte.

PS: Das, was Du als "Schlechtreden" Deines Ansatzes zu verstehen geruhtest, ist der Versuch einer Argumentation (es ist mir schon klar, daß Dir das eigentlich wesensfremd ist), warum ich die Änderung an der export-Zeile für die bessere Lösung halte.

Da ich aber nicht erkennen kann, aus welchem Grund Du meine Argumente "nicht nachvollziehen" kannst (auf Gegenargumente verzichtest Du ja und erklärst nur, daß Dich alle anderen Aspekte bei diesem Patch gar nicht interessieren), erübrigt sich tatsächlich jede weitere Diskussion und ich halte es für geboten, hier meinerseits zu schließen.

Sorry, Peter, der folgende Satz aus meiner Antwort

Ob ich den Wert direkt ins Environment reinschreibe (auf den Boxen, auf denen es geht) oder beim Auslesen so tue, als würde genau der Wert drin stehen, ist doch genau das gleiche.

ist doch genau die Begründung/die Argumentation, warum es mich gar nicht interessiert, was AVM in den Zeilen nach dem Auslesen macht. Und warum mein Ansatz durchaus gegen potentielle Änderungen an der Stelle gewappnet ist. Das hast du doch beides in Frage gestellt.

Edit: oder anders formuliert. Haben mich die Zeilen nach dem Auslesen zu interessieren, wenn ich den Wert direkt, persistent ins Urlader-Environment reinschreibe? Bin ich gegen die potentielle Änderungen von AVM an der Stelle gewappnet, wenn ich es direkt reinschreibe? Meine Antworten auf die beiden Fragen lauten: nein und ja.

Du versuchst doch zu argumentieren, die haben mich zu interessieren:

Dabei muß man den AVM-Code dann schon noch anschauen, wenn man verstehen will, was da eigentlich passiert

und ein "gewappnet" ist für dich nicht erkennbar (warum übrigens gegen "die letzte Zeile" - ich habe nie etwas in Bezug auf die letzte Zeile gesagt)

ein "gewappnet" gegen künftige Änderungen der letzten Zeile (EDIT: durch AVM) im oben gezeigten Ausschnitt kann ich nämlich nicht nachvollziehen - erst recht nicht, warum das bei einer Änderung der letzten Zeile durch den Patch nicht (oder mit geringerer Wahrscheinlichkeit) der Fall sein sollte.

Nein, das stimmt eben nicht und das hatten wir als Argumentation auch schon in der E-Mail.

Wenn Du tatsächlich den gewünschten Wert ins (EDIT: Urlader-)Environment schreibst, nachdem das System diese Schreibzugriffe gestattet und die Werte dort "zusammengebaut" hat (das "prom_getenv()" arbeitet bei verschiedenen Modellen da durchaus auch verschieden), dann ist das ein - absolut unnötiger - Schreibzugriff auf das TFFS und - wenn's schlecht läuft - tatsächlich sogar ein gesonderter, der nicht gemeinsam mit anderen (dank Caching) ausgeführt wird (und zwar bei jedem Bootvorgang).

Wenn sich jemand den Patch ansieht und den ggf. auf eine von AVM geänderte Firmware anpassen will oder muß, ist es allemal besser, wenn er dabei feststellt, daß der Patch die Stelle ändert, wo es am Ende auch entsprechende Auswirkungen hat und das ist das "export" - bei allem anderen davor kann das nach (theoretischen) Änderungen durch AVM noch eine geänderte Logik ergeben, die man dann zusätzlich überprüfen muß.

Den gesamten Teil "OEM ermitteln" könnte man auf die zwei "export"-Zeilen eindampfen (wenn man den Wert ohnehin fest vorgeben will), dann würde es noch übersichtlicher und die vorliegende Implementierung in Freetz ermöglicht es eben genau auch nicht, einen (ohnehin eher ungebräuchlichen) OEM_DEFAULT_INDEX zu verwenden, weil dann das Branding als "nicht unterstützt" angesehen würde in der "for"-Schleife: https://github.com/Freetz/freetz/blob/master/patches/scripts/101-enforce_branding_via_rc.conf.sh#L3 - das kann also als Begründung für vorher angestellte Überlegungen auch nicht greifen.

Ich habe mit den ganzen Worten versucht, Dir eine Gelegenheit zu bieten, eine plausible Erklärung abzugeben, warum Du in Freetz an genau dieser Stelle ändern willst oder mußt. Machst Du das nicht und änderst die Stelle aus meinen Vorschlägen (und die sind eben nicht neu, was ich versucht habe mit den Links zu "beweisen"), braucht es den Patch gar nicht erst, weil dann die Änderung in Freetz ebenfalls auf dem Wege erfolgt, den ich in "modfs" realisiert habe und den ich - seit langem - im IPPF für diesen Fall empfehle.

Wenn Du triftige Gründe dafür hast, das unbedingt in dieser Zeile ändern zu müssen und nicht an der Stelle, die ich - und zwar auch nach einigem Überlegen, was ich schon in der E-Mail vom 23.08. begründet hatte - ausgewählt habe, dann sollten diese ja auch überzeugend darzulegen sein und da sehe ich dann solche Sätze:

Warum in aller Welt muss ich mich mit den Zeilen nach dem Auslesen aus dem Environment beschäftigen?

oder auch

Es ist mir egal, was AVM nach dem Auslesen macht und wie die Änderungen an der Stelle ausschauen könnten - solange alle Auslese-Stellen erwischt sind und ein sinnvoller Wert als fixer Wert verwendet wird, kann nichts passieren, denn es ist das gleiche als würde dieser Wert in dem Environment stehen.

nicht wirklich als Versuch einer Argumentation an.

Auch wenn es Dich persönlich nicht interessieren mag, muß man auch die Interessen anderer berücksichtigen können und solange Du keinen wirklich triftigen Grund dafür hast, die Änderung nicht an der von mir empfohlenen Stelle, sondern an einer anderen auszuführen, ist das in meinen Augen ein vermeidbarer Unterschied, der ebenso durch die Änderung des Patches in Freetz behoben werden kann und wo es keiner Änderung des gui_bootmanager bedarf.

Mein Gott, mit "ins Environment reinschreiben (auf den Boxen, auf denen es geht)" ist das persistente Reinschreiben in die Urlader-Partition gemeint, das gleiche, was man über das Setzen über den Bootloader erreichen kann. Oder andersrum, mit "ins Environment reinschreiben" ist der alte Ansatz gemeint, der, den man verwendet hat, bevor AVM angefangen hat, die Bootloader-Versionen zu verwenden, die das persistente Verändern des Wertes verhindern.

Und die von dir zitierten Abschnitte sind sehr wohl die Argumente. Steht der Wert in dem Environment (weil es z.B. eine Original-Box ist oder weil man es über den Bootloader da rein geschrieben hat) ist es genau das gleiche als würde man beim Auslesen suggerieren, der Wert stünde dadrin.

Nur noch zur Info ... wenn ich von "letzte Zeile" schreibe, beziehe ich mich auf den oben von mir gezeigten Ausschnitt aus der "rc.conf" - weil Du irgendwo in den nachträglichen Änderungen wohl die Frage danach gestellt hast.

Aber ich kann meine Frage auch durchaus kürzer und prägnanter (dann vielleicht nicht mehr so "freundlich") formulieren:

Welcher Grund genau macht es für Dich (bzw. für Freetz) jetzt unumgänglich, an einer anderen Stelle als dem export OEM-Statement ein festes Branding zu setzen und dann auch noch vorzuschlagen, daß dieser Fall im gui_bootmanager zusätzlich zu berücksichtigen wäre? Was verhindert, daß man in Freetz die Branding-Geschichte jetzt so patcht, daß die vorhandene Lösung im gui_bootmanager auch mit Freetz funktioniert?

Auch wenn es Dich persönlich nicht interessieren mag, muß man auch die Interessen anderer berücksichtigen können und solange Du keinen wirklich triftigen Grund dafür hast, die Änderung nicht an der von mir empfohlenen Stelle, sondern an einer anderen auszuführen, ist das in meinen Augen ein vermeidbarer Unterschied, der ebenso durch die Änderung des Patches in Freetz behoben werden kann und wo es keiner Änderung des gui_bootmanager bedarf.

Auch diese Aussage ist interessant. Ich hätte den Patch aus diesem Pull-Request gleich in Freetz veröffentlichen können. Habe aber bewusst drauf verzichtet und habe es erst dir zukommen lassen, um dir entgegen zu kommen und das von dir an den anderen Stellen gewünschte "erst Diskutieren" zu ermöglichen. Ergebnis - egal, wie ich es mache - bist du nicht zufrieden ;-)

Du willst mir doch nicht wirklich ernsthaft einreden, daß Du die alternative Lösung, den Patch in Freetz eben so vorzunehmen, wie ich es vorgeschlagen hatte, nicht selbst erkannt hättest?

Jetzt wird es wirklich albern ... irgendetwas muß Dich ja trotzdem veranlaßt haben, das dann hier als Vorschlag zu unterbreiten.

Vielleicht willst Du ja doch noch begründen, warum Du in Freetz den Patch anders umsetzen mußtest, als ich es ursprünglich vorgeschlagen habe (und zwar nicht nur in der Mail an Dich)?

Du willst mir doch nicht wirklich ernsthaft einreden, daß Du die alternative Lösung, den Patch in Freetz eben so vorzunehmen, wie ich es vorgeschlagen hatte, nicht selbst erkannt hättest?

Den Satz verstehe ich (sprachlich) nicht - "die alternative Lösung, den Patch in Freetz eben so vorzunehmen, wie ich es vorgeschlagen hatte" - hmm?

Vielleicht willst Du ja doch noch begründen, warum Du in Freetz den Patch anders umsetzen mußtest, als ich es ursprünglich vorgeschlagen habe (und zwar nicht nur in der Mail an Dich)?

Ich fand es intuitiver. "Suggeriere man hätte den Wert ausgelesen" ist für mich intuitiver. Und das mit dem Entfallen der Notwendigkeit zu verstehen, was da alles rum herum geschieht.

Über die sprachlichen Schwierigkeiten kann ich Dir gerne hinweghelfen: Ich bin nicht bereit zu glauben, daß Du tatsächlich nicht in der Lage gewesen wärest, den Patch in Freetz so zu ändern, daß eine Änderung am gui_bootmanager überflüssig wird.

Ich fand es intuitiver. "Suggeriere man hätte den Wert ausgelesen" ist für mich intuitiver. Und das mit dem Entfallen der Notwendigkeit zu verstehen, was da alles rum herum geschieht.

Das ist also wieder mal kein objektiv nachvollziehbarer Grund, sondern eher "ein Gefühl" bzw. ein "ich fand ..." - dagegen kann man dann auch nur noch ein eigenes "ich finde" setzen und das sieht dann am Ende so aus:

##########################################################################################
## OEM Ermitteln
##########################################################################################
export OEM_DEFAULT_INDEX
export OEM=avm

Intuitiver und übersichtlicher geht es kaum noch und es ist auch simpel zu ändern, weil mit "OEM ermitteln" und "export OEM" die notwendigen Ankerzeilen vorhanden sind, um alles dazwischen zu entfernen. Auch hier gibt es nichts anderes mehr "rundherum", was man verstehen müßte.

Dieser Fall würde dann aber tatsächlich auch vom derzeitigen Stand des gui_bootmanager korrekt behandelt.

Um die Lösung aus deiner letzten Antwort umzusetzen, muss man doch davor verstanden haben, was alles rum herum geschieht und dass dieses "rum herum" tatsächlich komplett entfernt werden kann.

Mein Ansatz ist doch (das von dir unbeliebte) "es interessiert mich erst gar nicht", denn ich suggeriere "der Wert stünde drin". Wenn der AVM-Code für den tatsächlich in dem Environment stehenden Wert funktioniert, dann wird er auch für den suggeriere-Fall funktionieren. Mich interessiert (im Sinnde, nicht von Bedeutung) die Nachvollziehbarkeit der Stelle, an der der Eingriff erfolgt, gar nicht.

Eine Software zu patchen, deren Funktionsweise man nicht verstanden oder nicht untersucht hat, weil es "einen nicht interessiert", ist ein Vorgehen, was wohl mit dem "allgemeinen Verständnis" oder mit "best practices" nur schwer in Kongruenz zu bringen ist ... und es steht in eklatantem Widerspruch zu Äußerungen, die Du sonst so tätigst:

Dein Argument, der Code "wird nicht so oft geändert, deswegen muss er auch nicht besonders wartbar sein" kann ich nicht nachvollziehen. Jetzt haben zwei Leute daran gearbeitet bzw. arbeiten müssen/wollen und der zweite kam nicht sofort damit zurecht (im Sinne brauchte Zeit, um den Code zu verstehen zwecks seine Anpassungen durchführen zu wollen). Allein das ist schon Grund genug, um etwas Zeit in die bessere Verständlichkeit und damit die Wartbarkeit zu investieren.

Quelle: https://www.ip-phone-forum.de/threads/fehlende-bestandteile-im-opensource-paket-von-avm.287995/page-3#post-2215988 - und da kann man noch jede Menge andere Argumente Deinerseits nachlesen, warum Du bei anderen Gelegenheiten den Code genau deswegen wieder ändern mußtest, weil Du (obwohl es Dich gar nicht tangieren müßte) unbedingt verstehen mußt, was da genau passiert.

Offenbar ist das ziemlich selektiv, wann Du Dich für die eine Position (ich muß alles verstehen können und will das auch) und wann für die andere (interessiert mich nicht die Bohne, Hauptsache das Ergebnis stimmt) entscheidest ... man könnte den Eindruck gewinnen, daß es immer darauf ankommt, wie es Dir gerade am besten in den Kram paßt.

Aber wir sollten aufhören ... ich sehe nicht, daß wir hier vorwärts kommen werden und Du hast Deine Entscheidung getroffen, daß Du bei Deiner Implementierung bleiben willst (der Commit dokumentiert das).

Ich will nur noch mal festhalten, daß Du das keineswegs so umsetzen mußtest, wie Du es getan hast ... das ist erneut nur das Ergebnis, weil Du es so machen wolltest.

PeterPawn / YourFritz

gui_bootmanager: add support for "fixed branding"-approach used in Freetz #16