[PATCH 1/3] fff-sysupgrade: use keep.d and spread to packages

[Tim Niemeyer]

Moin Adrian

Am Sonntag, den 11.02.2018, 22:06 +0100 schrieb mail at adrianschmutzler.de:
> Hallo Tim,
> 
> ich habe gerade auf einem Router ins keep.d gekuckt:
> base-files            fastd                 uhttpd
> base-files-essential  uboot-envtools
> 
> Da ziehen wir also ggf. noch anderes Zeug mit (k.A. ob das jetzt gut oder schlecht ist).
> 
> Ich finde es irgendwie eklig, immer nachsehen zu müssen, welche Files rumliegen und die dann manuell zu überschrieben.
> 
> Die Aufteilung auf die Packages ist allerdings auch in meinen Augen
> erstrebenswert. Ich würde noch einen ganz anderen Ansatz vorschlagen:
> Wir können parallel zum keep.d einen "eigenen" Ordner keep.fff
> anlegen und dort packageabhängig Files reintun.
Jo, das hatte ich auch erst überlegt. Aber ich dachte: "lieber
möglichst nah am Original bleiben."

> Dass müsste man 0001-sysupgrade-no-config-save.patch behalten, aber halt
> > --		/etc/sysupgrade.conf /lib/upgrade/keep.d/* 2>/dev/null) \
> > -+		/etc/sysupgrade.conf /lib/upgrade/keep.fff/*  2>/dev/null) \
> 
> Nachteile wären in meinen Augen nur ein bisschen Speicher und die
> Tatsache, dass wir halt wieder einen Patch brauchen (ich finde den
> Patch aber weniger eklig als das manuelle überschreiben mit leeren
> Files).

Ein weiterer Nachteil wäre es, dass wenn wir (oder jemand) ein Paket
installiert, was den OpenWRT Weg nutzen möchte, dass dies dann nicht
geht.

Im Beispiel von uhttp muss ich sagen, gefällt es mir eigentlich sehr
gut, so wie das gelöst ist.

> Als Vorteile hätten wir, dass wir sicher nur unsere Files nehmen und
> nicht immer zwischen install und install-overlay unterscheiden
> müssen.
> Und wir müssen nicht bei jedem LEDE-Update nachsehen, ob sich das
> keep.d geändert hat (was sicher leicht vergessen wird).
Das ist auf jeden Fall wahr. So lange wir dieses OpenWrt nur für die
von uns vorgesehenen Zwecke nutzen scheinen die Vorteile von deinem
Vorschlag zu überwiegen.

Da das Zeug eh erst im next-feature drauf soll haben wir noch etwas
Zeit. Ich würde das jetzt noch ein bisschen in der Diskussion lassen
und je nach dem ggfs mein Patch an deinen Vorschlag anpassen. Hätte da
gern aber noch ein paar mehr Meinungen.

Tim

> Grüße
> 
> Adrian
> 
> 
> > -----Original Message-----
> > > > From: Tim Niemeyer [mailto:tim at tn-x.org]
> > Sent: Sonntag, 11. Februar 2018 21:53
> > > > To: mail at adrianschmutzler.de; franken-dev at freifunk.net
> > Subject: Re: [PATCH 1/3] fff-sysupgrade: use keep.d and spread to packages
> > 
> > Am Sonntag, den 11.02.2018, 21:45 +0100 schrieb
> > mail at adrianschmutzler.de:
> > > Hallo,
> > > 
> > > ich bin mir noch nicht so ganz sicher, ob ich das jetzt richtig
> > > verstanden habe:
> > > 
> > > > Den reinen OpenWRT Mechanismus können wir nach wie vor nicht
> > 
> > nutzen,
> > > > weil dann immer noch Config's überleben, die wir eigentlich gern
> > > > überschreiben möchten. Daher wird dieser Mechanismus mit diesem
> > > > Patch auch ausser Kraft gesetzt in  dem die entsprechenden files in
> > > > /lib/upgrade/keep.d überschrieben werden.
> > > 
> > > Du löschst ja jetzt 0001-sysupgrade-no-config-save.patch, d.h.
> > > zunächst werden jetzt alle keep.d/*, die da von OpenWRT drin stehen,
> > > wieder aktiv?
> > 
> > Ja, korrekt. Aber von OpenWRT stehen nicht mehr so viele drin. (siehe
> > unten). Neu ist lediglich die ssl keys vom webui.
> > 
> > > 
> > > > > > diff --git
> > > > > > a/src/packages/fff/fff-fastd/overlay/lib/upgrade/keep.d/fastd
> > > > > > b/src/packages/fff/fff-fastd/overlay/lib/upgrade/keep.d/fastd
> > > > > > new file mode 100644
> > > 
> > > Hier legst du mittels install-overlay ein neues, leeres File an, das
> > > das bestehe File überschreibt, sodass fastd NICHT das Upgrade überlebt
> > > (weil wir das ja so wollen)?
> > 
> > Genau. Die fastd Config soll ja vom vpn-select angelegt werden. Das macht
> > vermutlich langfristig Sinn das mal irgendwie zu ändern. Ob die Config dann
> > überleben soll oder nicht muss das fff-fastd Packet entscheiden. Vor und mit
> > dem Patch überlebt es nicht.
> > 
> > > Ist das auch der Grund, warum du manchmal files/* und manchmal
> > > overlay/* verwendest, je nachdem, ob ein bestehendes file
> > > überschrieben werden muss oder nicht?
> > 
> > Ja, man kann im Package/<Name>/install keine Dateien von anderen
> > Paketen überschreiben. Das rootfs-overlay ist so eine Art Zwischenschritt, in
> > welches Dateien installiert werden können. Der Inhalt von rootfs-overlay
> > wird am Ende vom Build-Prozess dann in das rootfs geschoben. Am Ende
> > überschreibt es dann Dateien.
> > 
> > Mir persönlich gefällt das Vorgehen so gar nicht, aber die einzigen anderen
> > funktionale Alternative sind
> > * die Dateien über uci-default zu löschen. Dann hat man den "dreck"
> > aber trotzdem im Image und auf dem Flash.
> > * die Dateien über das files/ Directory zu überschreiben. Das wollten wir aber
> > los werden, weil es keine Abhängigkeiten und Paket-Strukturen kennt. Es
> > würde Dateien überschreiben, auch wenn das überschreibende Paket nicht
> > gebaut wird.
> > 
> > Es gab ein neues buildroot Feature, was auch kurz in OpenWRT ging. Da
> > konnte man mittels Buildroot-Overlay die Makefiles von anderen Paketen
> > beeinflussen. Das wäre eine saubere Lösung gewesen, aber aufgrund der
> > Komplexität wurde (oder wird) es aus OpenWRT entfernt.
> > 
> > Tim
> > 
> > > Grüße
> > > 
> > > Adrian
> > > 
> > > 
> > > 
> > > 
> > > 
> > > > -----Original Message-----
> > > > > > > > From: Tim Niemeyer [mailto:tim at tn-x.org]
> > > > Sent: Sonntag, 11. Februar 2018 21:34
> > > > > > > > To: mail at adrianschmutzler.de; franken-dev at freifunk.net
> > > > Subject: Re: [PATCH 1/3] fff-sysupgrade: use keep.d and spread to
> > > > packages
> > > > 
> > > 
> > > ....
> > > 
> 
> 
-------------- nächster Teil --------------
Ein Dateianhang mit Binärdaten wurde abgetrennt...
Dateiname   : signature.asc
Dateityp    : application/pgp-signature
Dateigröße  : 488 bytes
Beschreibung: This is a digitally signed message part
URL         : <http://lists.freifunk.net/pipermail/franken-dev-freifunk.net/attachments/20180211/9da3d6c1/attachment.sig>