search

Freetz / freetz

Freetz firmware extension/modification for the ​AVM FRITZ!Box series and devices with identical hardware
https://freetz.org
GNU General Public License v2.0
300 stars 160 forks source link

adding own static packages appendig 'dirty' in version string #321

Open WileC opened 4 years ago

WileC commented 4 years ago

Wenn ich ein eigenes addon in die /addon/static.pkg eintrage und den make durchlaufen lassen, wird zwar alles ordnungsgemäß in die Firmware gepackt, aber der Version-String durch das /tools/freetz-version mit einen "-dirty" versehen ...

Liegt das daran, dass das Verzeichnis /addon/ nicht in der .gitignore drin steht? .. Das Verzeichnis dort eintragen macht aber auch nicht wirklich sinn, da sonst Änderungen durch das Repo nicht übernommen werden oder?

f-666 commented 4 years ago

Effektiv ja. Ich glaube schon die Veränderung der .gitignore macht das Repository "dirty".

PeterPawn commented 4 years ago

dirty / unclean / tainted - was wäre die richtige "Beschreibung" des Umstands, daß es sich nicht um einen "clean build" handelt, bei dem nur die Pakete und Einstellungen aus dem "Original" verwendet wurden? AVM hängt ein "M" an die Build-Nummer an und schaltet bestimmte Funktionen in den Kernel-Quellen auch nur dann frei, wenn dieses "M" vorhanden ist (Kernel-Funktion avm_fw_is_internal zur Abfrage).

Letztlich geht es ja auch in Freetz nur darum, schon an der Versionsangabe zu erkennen, ob Änderungen erfolgt sind - und das ist natürlich auch dann schon gegeben, wenn man eigene Pakete hinzugefügt hat.

Wobei das wieder einfach "zu umgehen" wäre - man erstellt seinen eigenen Fork vom Ursprung und packt da sein eigenes Paket in den "addon"-Zweig. Dann checkt man dieses eigene Repo aus und baut sein(e) Image(s) mit dem - da es hier keine (weitere) Änderung gibt, schlägt auch freetz-version nicht zu.

Wenn man sich nur am "dirty" stört, kann man das in der freetz-version ja auch deaktivieren (https://github.com/Freetz/freetz/blob/master/tools/freetz-version#L54). Der Test ist ohnehin nicht zu 100% aussagekräftig, da zusätzliche Patches für Pakete nicht automatisch zum "-dirty" führen - weil eben "untracked changed" dank -uno ignoriert werden und weitere Patch-Files für ein Paket wären ja "untracked".