Es handelt sich erst einmal um zwei verschiedene Kernel-Versionen, 3.3.8 auf Dragonworth und 3.13.5 auf Sunray und Lonrisun.
Der Treiber für 3.3.8 macht ein paar kernel calls, die damals schon deprecated waren, aber erst in 3.10.x entfernt wurden.
Wenn das nicht wäre, würde der 3.3.8er Treiber auch unter 3.13.5 noch laden (Wenn man die VERMAGIC patcht).
Ich habe mal damit angefangen, die deprecated kernel calls wieder reinzupatchen (Das stört ja die neueren Treiber nicht, die sie gar nicht benutzen), aber das ist kaum über den Ansatz hinausgekommen.
Du berücksichtigst eines nicht:
An je mehr Stellen ich den Startvorgang verändere, von desto mehr Paketen bin ich abhängig.
Der Sunray sind im Prinzip alle Updates egal, man kann die alle einspielen (Nur darf sich die Kernel-
Version, also der Part "3.13.5", nicht ändern), solange die eine Treiber-Datei mit der Time-Bomb nicht ersetzt wird.
In Bezug auf die Sunray denke ich daher im Moment eher darüber nach, die Eingriffe zu reduzieren.
Bei der Lonrisun darf sich zusätzlich auch das Kernel-Image nicht ändern, denn das erhält - außer bei OpenPLi - einen Patch für die neueren "Proxy"-Treiber, aber ansonsten dürften sich auch dort alle anderen Kernel-Pakete (DVB-, WiFI-, Serial-, ... Treiber) ändern.
Viel zu aufwändig:
Wenn sich das System einmal auf einen Treiber eingestellt hat, kann die enigma2-Binary auch einfach passend gehalten werden.
Bei der Sunray passiert da auch gar nix, da ist die normale enigma2-Binary des Original-Images drauf, aber für Lonrisun und Dragonworth muß sie bei jedem Update neu ersetzt werden (Deshalb gibt es auch an manchen Tagen kein Image für Lonrisun: Dann waren die enigma2-Pakete für die Spender-Box und die Solo² nicht synchron).
Wie schon gesagt, eine fake-vugles-Library würde das eleganter lösen ... damit fiele der Grund für den Austausch nämlich weg.