Ich habe eine Frage zur distfeeds.conf welche mit dem Gluon ausgeliefert wird.
Gibt es einen Grund warum der Verweis auf die OpenWRT Core-Pakete standardmäßig auskommentiert wird?
Hintergrund:
Ich habe letztens für eine FF-Firmware / Gluon Installation auf meinem Raspberry PI ein paar Kernel-Module für ein USB-Ethernet-Dongle nachinstallieren müssen und dafür musste ich die URL für die richtige Kernel-Version wieder in die distfeeds.conf (bzw die customfeeds.conf) einpflegen.
Daraus ergeben sich 2 Fragen:
1.) Warum wird der Link auf die OpenWRT Core-Pakete in der distfeeds.conf standardmäßig auskommentiert?
ABER:
Warum basiert eine Gluon Version immer auf der neusten Snapshot Version von OpenWRT und nicht auf einer „festen“ Version (z.B. 19.07.5)?
Dann könnte man z.B. in der distfeeds.conf immer die passende OpenWRT Core Pakete verlinken.
Wo ist der Vorteil den aktuellen Snapshot zu verwenden?
Meinem Eindruck nach ist die Gluon Entwicklung nicht so agil, das man immer auf dem nächsten Nigthly Build aufsetzen müsste…
Ich fürchte das ist jetzt eine längere philosophische Frage zu einem eher theoretischem Problem geworden, aber ich würde mich freuen eure Meinungen zu lesen!
Nicht unbedingt, da die patches von Gluon selbst auf einem tagged OpenWrt release potentiell die ABI verändern.
Der Vorteil ist, dass fixes aus dem release branch schneller bei Gluon ankommen, ohne dass die einzelnen patches downstream getracked werden müssen.
Betreibt deine Community keinen download-server für OPKG pakete? Wenn das der Fall ist und du dein Image selbst kompilierst sollte ein manuelles anpassen der OPKG repositories nicht nötig sein.
Okay, das ist natürlich ein Argument.
Aufgrund der Abstände der Gluon Releases, hatte ich angenommen, dass viele der OpenWRT Patches eh manuell getrakt bzw. neue Funktionen / Unterstütze Modelle etc. manuell getestet werden.
Aber so ist es natürlich einfacher eine neue Gluon Version zu bauen!
Bei uns gibt es keinen separaten Download-Server für die OPKG Pakete und ich habe mein Image auch nicht selbst kompiliert.
Ein paar Gedanken im Nachgang:
Bei einem Downloadserver müsste man ja auch jedes neue Gluon Release einmal alle neuen Pakete nochmal vorhalten. Sonst meckert Gluon bzw. Openwrt, dass die vorgehaltenen Kernelmodule nicht zu aktuellen Version passen)
Hiermit verschiebt man aber auch nur die Arbeit des Anpassen der Repopfade bzw. das Pflegen des Repositories auf die Admins.
Es wäre halt schon schick, für die Admins und die bastelwilligen User, wenn man sich nicht mehr um die „richtigen“ Repopfade kümmern müsste.
Aber wie schon in der Ausgangsfrage geschrieben:
Eher eine theoretisches Problem, weil man in der Regel die zusätzlichen Pakete eher selten benötigt.
Häufig™ haben die lokalen Maintainer den Upload irgendwann „wegen sträflicher Nichtnutzung“ aufgegeben.
In dem Fall hilft es evtl, einfach mal lokal nachzufragen, ob man die vielleicht doch bekommen kann.
(Zumindest freuen sich dann Leute ob der Nachfrage.)
Wie gesagt: Ich kann das gut verstehen, warum man sich den Stress nicht machen will.
Normalerweise brauch man die Pakete ja auch nicht.
Genau deshalb wäre es halt cool, wenn Gluon direkt einen funktionierenden Link an Bord hätte.
Als Maintainer muss man die Pakte die ja eh bei openwrt.org liegen nicht nochmal extra irgendwo ablegen und sich drum kümmern, dass immer die richtige Version verlinkt ist.
Als „bastelwilliger User“ kann man direkt auf die extra Pakete zugreifen, ohne große Klimmzüge machen zu müssen.
Ich wollte dich und plaste nicht mit meinen Spielereien nerven…
Ich habe mir die richtige Version der Kernel-Packages rausgesucht, den Link nachträglich manuell zusammen gebaut und die Packages dann direkt geladen.
Kein Problem, das archiv lag seit Monaten auf dem FW-Server in meinem Home-Direcotry, ich hatte es nur die ausgepackt und an den „richtigen“ Pfad verschoben.
Voila:
Dort ist mit einem Beispiel beschrieben, wie in der site.conf die Package-Links verwaltet werden können.
Für Firmware-Bauer sollte es eigentlich aufwandslos möglich sein, die eigenen Build-Release abhängigen Kernelmodule zusätzlich eineindeutig über den Firmware-Downloadserver mit anzubieten.
Das Gluon-Projektteam hat sich jedoch dagegen entschieden, so etwas anzubieten.
Und es hat sich in der Community meines Wissens bislang auch niemand gefunden, der soetwas zentral anbietet.
Daher müssen -wie PK2061 schreibt- es die jeweiligen Domain-Firmwarebauenden (Admins/Users) lokal tun. (Und ja, das ist eine politische Entscheidung mit Pros und Cons, die ich hier keinesfalls bewerten möchte.)
