Die Kernel-Header, die mit slhs Framework gebaut wurden, haben die Abhängigkeit zum linux-kbuild-2.6.37 nicht.
Mal ganz ehrlich, was soll das - ich will eigentlich nicht den Gernot Hassknecht geben, aber
Für debian-Kernel, die nicht slh heissen, brauche ich ein linux-kbuild. Ausnahme: Kernel, die auf slh basieren. Dass sich meine Begeisterung über die ein oder andere Entscheidung, die slh getroffen hat, in recht eng dimensionierten Grenzen bewegt, habe ich wohl deutlich zum Ausdruck gebracht. Das hat aber nichts mit der Qualität der Arbeit an sich, sondern einzig und allein mit dem Verzicht auf BKL zu tun.
Kernel, die im experimental hängen, sind ohne linux-kbuild für
mich wertlos, ich kann nicht mal die Header dazu installieren. In meinem Fall heisst das: Kein Catalyst. Auch dazu habe ich meine ganz persönliche Meinung.
agaida@aptosid:~$ apt-rdepends linux-headers-2.6.37-trunk-all
Paketlisten werden gelesen... Fertig
Abhängigkeitsbaum wird aufgebaut
Statusinformationen werden eingelesen... Fertig
linux-headers-2.6.37-trunk-all
Hängt ab von: linux-headers-2.6.37-trunk-all-amd64 (= 2.6.37-1~experimental.1)
linux-headers-2.6.37-trunk-all-amd64
Hängt ab von: linux-headers-2.6.37-trunk-amd64 (= 2.6.37-1~experimental.1)
linux-headers-2.6.37-trunk-amd64
Hängt ab von: gcc-4.4
Hängt ab von: linux-headers-2.6.37-trunk-common (= 2.6.37-1~experimental.1)
Hängt ab von: linux-kbuild-2.6.37
Ich gebe ja zu, dass ich ein wenig halsstarrig bin, aber das hat einen Vorteil, mein Zeug funktioniert so, wie ich das haben will. Ich habe nicht vor, mir vorschreiben zu lassen, welche Hardware und welche Treiber ich zu benutzen habe. Wenn ich dann durch Tests dazu gebracht werden kann, meine Meinung zu ändern, ist das in Ordnung. Ich muss aber die Chance haben, mir meine Meinung zu bilden. Das absolutistische Ausschließen bestimmter Optionen mit dem Hinweis, dass das jetzt einfach so sei, dient nicht dazu, meine Laune in irgendeiner Weise zu verbessern. Dazu bin ich dann doch zu eigenständig.