Das mit dem Stil meinte ich ja mit noch nicht überarbeitet. In ein Wiki gehören eigentlich offizielle Texte, aber das ist mein Zettelkasten, während dreier Kernel-Bau-Sessions entstanden. Das ist der Grobentwurf eines Entwurfs, jede Hilfe ist willkommen.
Bis auf dass es funktioniert und in der Realität getestet wurde und Bestand hatte, nichts großes. Das mit den Bedingungen ist richtig. Es spricht meines Erachten nichts gegen den Einsatz von debuild für den lokalen Einsatz, aber eigentlich sollte das Teil in einer neutralen Build-Umgebung mit pBuilder erstellt werden.
Ich hab bei so etwas immer ein leichtes Zeitproblem. Die Scripte nachvollziehen und richtig einsetzen ist eigentlich das Wesentliche, ich hab auch nur 2 Tage gebraucht, bis ich damit durch war. Die Zeit hat sich gelohnt, bequemer und sicherer geht es nicht. Die Idee mit den Diff's fand ich gut, ein Diff sagt mehr als tausend Worte. Die Konfigurationen sollte man schon per Hand anpassen, mir war eigenlich nur die Darstellung +/- im Kontext wichtig.
Quilt habe ich rausgenommen, weil ich mit quilt immer von einer definierten Basis ausgehen muss. Ohne Quilt passt das besser in mein Schema mit reprepro, sprich fertiges Quellpaket nehmen, Orginalquellen wegwerfen, alles neu erstellen und gut ist gewesen. (Patches und Series kann eigentlch ganz raus, das ist wirklich für richtig Fortgeschrittene, vor allem auch das momentane Hauptkampffeld bei Änderungen. Dem begabten Amateur sei geraten, sein Zeug einfach am Ende draufzuhauen, oder noch besser, komplett die Hände draus zu halten)
Was auf jeden Fall noch Erwähnung finden sollte (imho in einem eigenen Artikel), ist der Aufbau der Konfiguration. Natürlich kann man die Konfiguration des laufenden aktuellen Kernels in make xconfig oder gconfig weiterbearbeiten. Diese würde ich dann speichern und per meld oder bcompare in slh's Konfig-Schema bringen. Hier könnte man auch mit einem wie auch immer gearteten Script zuschlagen, da müsste ich mal drüber nachdenken.
Als weiterführenden Artikel (für bequemes Arbeiten) wäre ein Verweis auf git und einige Arbeitsweisen sicherlich sinnvoll und angebracht. Im Endeffekt ist ja jede Anpassung gegen die aktuellen Quellen ein 3-way-merge, da sollte man schon die eine oder andere Zeile zu schreiben, es lohnt sich. git setze ich deswegen ein, weil es beim Basteln keine schönere Möglichkeit gibt, die Quellen sauber und fehlerfrei zu halten. Würde zwar auch so gehen, aber ist für mich dann nicht mehr nachvollziehbar. Bei so was bin ich aus Erfahrung Kontrollfreak. Git hat vor den anderen Versionskontrollen den entscheidenden Vorteil, dass es sauschnell ist. Bei anderen Projekten setze ich die Prioritäten anders und setze auf svn.
Zum Thema Repo aufsetzen: Da es einige Varianten dafür gibt, hab ich mir diese natürlich auch angeschaut. So richtig begeistert war ich eigentlich bis jetzt von keiner, reprepro hatte aber den grandiosen Vorteil, dass es einiges an Komfort mitbringt, wenn man es verstanden hat. (Davon bin ich zwar noch relativ weit entfernt, aber was solls) Da ich bisher nie die Notwendigkeit sah, mich mit so was zu beschäftigen, war auch das wieder Grundlagenforschung für mich. Bei Ubuntu hatte und habe ich Launchpad, bei Arch ist es noch bequemer, da nimmt man das AUR für Sachen, die auch die Allgemeinheit haben soll, man kann sich ein eigenes AUR bauen oder aber auch recht einfach ein eigenes Repository pflegen. Bei debian ist das halt nicht so verbreitet, weil relativ wenige Leute bauen.