Es ist ziemlich offensichtlich, dass die Betreuung des Debian Kernel Repos, das ich in diesem Artikel angekündigt hatte, einiges an Arbeit ist – gerade da ich den Kernel in 4 „Geschmacksrichtungen“ anbiete: Vanilla, VM und beide Arten mit dem Gentoo Patchset – mit anderen Worten: Es mussten Verbesserungen her – und zwar schnell. Die Einführung von ccache brachte zwar eine leichte Verbesserung (12-15% Cache Hits), aber das ist auch alles Andere als ‚viel‘ oder ‚Großartig‘.

Der zweite Schritt war ein Build-Script, damit ich nicht alle Schritte händisch zu machen hatte und das Zeug sich selbst baut anstatt auf mich zu warten. Es war keine große Sache, ein einfaches Batch-Script, das seinen Job tat. Aber unterm Strich war es mir zu unflexibel für das, was ich das Script gebraucht habe. Aufgrund der fehlenden Fehlererkennung funktionierte das Script obendrein nur, wenn alles glatt lief – also in einer nicht-vorhandenen, perfekten Welt.

Also zurück an den Start:

Das Erste was ich brauchte, war Config-Management um die Konsistenz der Config für jeden Kernel zu gewährleisten. Git ist für solche Sachen großartig und Github bietet mir entsprechende Sicherheit gegen Plattenausfälle. Super.

Das nächste Problem, das ich lösen wollte war eine ‚Ein Script sie zu knechten‘-Lösung um nicht vier Scripts zu haben, die alle relativ das Gleiche tun. Also war es an der Zeit alles in Funktionen zu kapseln und einige IFs in den Code zu werfen um die vier Geschmacksrichtungen zu erhalten. Nicht ganz perfekt, aber schon eine weitere Verbesserung.

Unser nächstes Ziel war nun kaputte Builds bzw. Patches die nicht funktionierten – also alles was mir die Builds ruiniert – abzufangen. Das war kein großes Ding mehr, da ich ja alles in Funktionen aufgebrochen hatte. Bei Auftreten eines Fehlers konnte ich so sauber aussteigen ohne die Config wieder in mein Repo zurückzuschreiben, was mir am Ende einige Rollbacks meines Repos erspart.

Jetzt ist die Sache zwar schon funktionstüchtig, aber wenig komfortabel, da ich immer noch die exakte Kernel-Version heraussuchen musste um den neuen Kernel zu bauen. Ein bisschen curl hier, grep da und schon hatten wir die neueste Version herausgefunden:

KERNEL_VERSION=`curl -s https://www.kernel.org | grep -A1 latest_link | tail -n1 | egrep -o '>[^<]+' | egrep -o '[^>]+'`

Warum eigentlich alles in Bash? Ich muss zugeben, diese Frage wurde mir bereits einige male gestellt und die Antwort ist eigentlich nicht schwer: Ich will das Script leicht pflegen können und es in zB C zu schreiben würde mir keinen nennenswerten Vorteile bringen, da ich ohnehin viele shell-exec Aufrufe tätigen muss.

Das Script selbst tut seinen Job und was noch blieb war die Config auszulagern, wie ich in diesem Beitrag beschreibe, da ich diesen Artikel nicht noch weiter in die Länge ziehen wollte.