Backports und die Philosophie von Debian.

[Animefreak79]

Joa... Hab mich seit längerem mal mit dem Thema Backports beschäftigt, mich allerdings entschieden, die Finger davon zu lassen. Nachdem ich das hier gelesen hab: https://backports.debian.org/Instructions/ Vor allem: "Backports cannot be tested as extensively as Debian stable, and backports are provided on an as-is basis, with risk of incompatibilities with other components in Debian stable. Use with care!" Die Philosophie, zumindest im Bezug auf den Stable-Zweig ist doch die, ein möglichst stabiles und gründlich getestetes System bereitzustellen, oder? Versteht mich nicht falsch, maximale Konfigurierbarkeit ist sicher etwas sehr Feines, gerade wenn gewisse Spezialfälle vorliegen. Aber... Ich bin nicht wirklich ein Unix-Experte. Bin kein absoluter Linux-Newbie mehr, habe auch sicher keine Angst vor der Konsole oder brauche für jede Kleinigkeit ein grafisches Konfigurationswerkzeug, nichts desto Trotz möchte ich gerne ein OS haben, das einfach funktioniert und mir nicht auf den Senkel geht! Diese Einstellung ist eine Folge einiger ziemlich nervigen Erlebnisse mit Linux Mint, die zur Folge hatten, dass ich zu Debian gewechselt bin. Und siehe da... Es läuft erheblich perfomanter und vor allem superstabil, ohne bisher ein einziges größeres Generve, die Systemwerkzeuge sind in großen Teilen dieselben wie bei Mint, weshalb keine wesentliche Umstellung erforderlich ist (ich bin ein Asperger-Mensch, deshalb habe ich so meine Schwierigkeiten mit größeren Veränderungen), Distributionswechsel kommt wohl nicht mehr in Frage, alles ist supi.^^ Würde ich aber jetzt beispielsweise einen Backport-Kernel nutzen, um neue Kernelfeatures bzw Security-Patches auch unter Stable zu benutzen, ist gerade die von mir so sehr geschätze Stabilität etwas gefährdet, sofern ich richtig gelesen habe (meine Englischkenntnisse sind aber ganz okay). Eigentlich möchte ich die Vorteile durch die Stable-Philosophie von Debian ungern wieder zunichte machen... Diese meine Sichtweise kann doch eigentlich ganichtmal so verkehrt sein...

[Radfahrer]

Das "Stable" hat nichts mit der Laufstabilität zu tun, heißt also nicht, dass das System nicht abstürzt.
Stabil im Sinne von Debian stable bedeutet, dass die Softwareversionen stabil, also dieselben bleiben. Das hat den Vorteil, dass man nicht ständig mit neuen Versionen und Features zu tun hat, was in einem größeren Firmenumfeld erhebliche Arbeit bedeutet.
Es gibt einige wenige Ausnahmen, wie z.B. Browser, die auch in stable bei Bedarf aktualisiert werden. Ansonsten gibt es nur Sicherheitsupdates.

Dass Debian auch stabil und ohne Abstürze läuft, ist ein angenehmer Nebeneffekt.

[Animefreak79]

Es gibt einige wenige Ausnahmen, wie z.B. Browser, die auch in stable bei Bedarf aktualisiert werden. Ansonsten gibt es nur Sicherheitsupdates.

Diese Tatsache ist mir durchaus bekannt, aber gerade dadurch, dass die Programmversionen so weit es geht dieselben bleiben, und in jeder Stable-Veröffentlichung nur Software aufgenommen wird, die ausführlich getestet ist, entsteht doch auch einen großen Vorteil, was die Laufzeitstabilität betrifft, oder? Unter Mint ist mir, um nur ein eher nichtiges Beispiel zu nennen, oft mehrmals in der Woche schon beim Hochfahren des Systems der X-Server abgeschmiert, mit dem Ergebnis, dass der PC nur durch ein MagicSysRQ wieder zum Leben zu erwecken war... Derartige Erlebnisse hatte ich unter Debian 9 bisher kein einziges Mal. Und wenn ich schon auf der offiziellen Website lese, dass es durch die Nutzung von Backports (auch dadurch, dass diese eben nicht so ausführlich getestet werden können) möglicherweise zu Inkompatibilitäten kommen kann, ist dies für mich ein Grund, eben diese (sofern es nicht wirklich äußerst trifftige Gründe gibt) wenn möglich nicht zu nutzen. Ich halte mich da lieber, auch weil ich eher der durchschnittliche Ottonormal-User bin, an die Empfehlungen des Debian-Projektes, was bestimmt nicht so falsch sein kann.

[owl102]

und in jeder Stable-Veröffentlichung nur Software aufgenommen wird, die ausführlich getestet ist

Nein, das ist nicht so.

Es gibt vor dem Branch aus Testing zu Stable den "Freeze" bei Testing. In dieser Periode werden nur noch Fehler gefixt, und es gibt keine neueren Versionen aus Unstable/sid in Testing. Durch diese Zeit wird eine gewisse Extra-Fehlerfreiheit bewirkt.

Fehler, die in dieser Periode aber nicht gefunden werden, werden auch innerhalb der "stable" Debian-Version nicht gefixt, auch nicht zu einem späteren Zeitpunkt. Bei Debian 8 war das zum Beispiel der matschige NTFS-Treiber und Totem, welches Videos nur ruckelnd darstellt, sobald man zu viele Videos in dem Verzeichnis "Videos" hat. (Beides Fehler, die in Upstream gefixt wurden.) Bei Debian 9 ist zum Beispiel das Subclipse-Plugin von Eclipse kaputt, und wie wir aus mehreren Threads hier wissen auch software-properties-gtk, die graphische Verwaltung der sources.list.

[breakthewall]

Persönlich halte ich nichts von den Backports, da das für mich ebensowenig Sinn hat wie ein Debian-Stable. Denn Software ist niemals stabil noch fertig, was den Nutzen eines solchen Repositorys schon in Frage stellt. Davon abgesehen ist das ein einerseits ein Risiko und auch ein erheblicher Aufwand, diverse Patches auf ältere Software zu übertragen, was eine modernere Softwareversion schon grundlegend vermieden kann. Und im Bezug auf Sicherheitslücken, ist man unter Debian-Unstable meist schneller abgesichert, ehe Patches für Debian-Stable herausgegeben werden. Sicher mag es nun wieder jene Argumente geben, dass neue Software wiederum neue Sicherheitslücken mit sich bringen kann, doch diesbezüglich gibt es stetig Fortschritte, was schon beim Compiler beginnt und diversen Fuzzing-Tools die angewendet werden. Nutze jetzt schon so viele Jahre Debian-Unstable, ohne auch nur irgendein besonders gravierendes Problem aufgrund der Nutzung.

[tobo]

Würde ich aber jetzt beispielsweise einen Backport-Kernel nutzen, um neue Kernelfeatures bzw Security-Patches auch unter Stable zu benutzen, ist gerade die von mir so sehr geschätze Stabilität etwas gefährdet...

Wenn dir tatsächlich Funktionalität oder Hardware-Unterstützung im stabilen Kernel fehlt, dann musst du halt abwägen bzw. es bleibt dir nichts anderes als die Backports. Wegen Sicherheits-Updates musst du aber keinen Backport-Kernel installieren - die fließen auch für den stabilen Zweig ein. Dort werden auch normale Fehler behoben, die keine sicherheitskritischen Aspekte haben. Allerdings müssen diese Fehler dann so gravierend sein, dass sie die Funktionaltität des Programms infrage stellen. Das ist dann also eher selten der Fall. Ist das nicht der Fall, dann kommen die Backports ins Spiel. Solange es sich hier um einzelne Pakete handelt, wirst du im Zusammenspiel mit anderen Paketen kaum Probleme bekommen. Wenn doch, dann ist ein Downgrade zurück auf das Stretch-Paket mittels "apt-get install PAKET/stretch" normalerweise aber kein Problem. Dass du dir hier richtig weh tust, dann muss schon viel passieren!? Aber trotzdem, Backports sollten die Ausnahme sein. Oder anders gesagt, es sollte einen triftigen Grund dafür geben (wie du ja auch schreibst).

Der Grund, dass z.B. die Security-Updates in stable langsamer eintreffen als in sid liegt darin, dass sie zuerst durch proposed-updates wandern. Dieses Repository könntest du ebenfalls in deiner sources.list einbinden und somit zeitlich direkten Zugriff auf die Updates erlangen. Aber es hat natürlich auch einen Sinn, dass die Updates in proposed erstmal unter Beobachtung stehen. Sicherheit vor Schnelligkeit. Aber auch hier sollte bei Problemen der Downgrade sehr einfach funktionieren. Wenn du ein Update aber wirklich dringend benötigst, dann ist proposed was für dich.

[Animefreak79]

Okay, klingt als ob man Backports so oder so nur in Ausnahmefällen nutzen sollte, oder halt..

Der Grund, dass z.B. die Security-Updates in stable langsamer eintreffen als in sid liegt darin, dass sie zuerst durch proposed-updates wandern. Dieses Repository könntest du ebenfalls in deiner sources.list einbinden und somit zeitlich direkten Zugriff auf die Updates erlangen. Aber es hat natürlich auch einen Sinn, dass die Updates in proposed erstmal unter Beobachtung stehen. Sicherheit vor Schnelligkeit. Aber auch hier sollte bei Problemen der Downgrade sehr einfach funktionieren. Wenn du ein Update aber wirklich dringend benötigst, dann ist proposed was für dich.

Aber wohl trotzdem auch nur, wenn es wirklich nötig ist, denke ich doch mal.

Vermutlich sind solche Spezialfälle wohl eher selten (aber wohl auch nicht gänzlich ausgeschlossen). Wie schon gesagt, als ich noch Mint benutzt hab, ist mir relativ häufig der X-Server beim Hochfahren abgestürzt, der XFCE-Desktop konnte nicht richtig gestartet werden, nichts funktionierte mehr, es war nicht einmal möglich, auf eine virtuelle Konsole zu wechseln. Also MagicSysRQ und Neustart, danach war dann wieder alles in Ordnung. Tjoa, und seitdem ich Debian nutze, tritt dieses Problem bei mir garnicht mehr auf. Ebenfalls waren unter Mint häufig nach einem Update plötzlich die Pakete von Calligra defekt, und nicht einmal ein

Code: Alles auswählen

apt-get -f install

hat geholfen. (Oder besser gesagt ein sudo apt-get -f install da es sich bei der Beschreibung ja um Mint handelte.^^) Ebenfalls bei dem Problem nutzlos ein

Code: Alles auswählen

dpkg --configure -a

Alles Probleme, die Geschichte sind, seit ich von Mint zu Debian gewechselt bin, und die mich leider traumatisiert haben, weshalb ich mich halt irgendwie nicht traue, einen Eingriff in mein gut funktionierendes System vorzunehmen, wo schon auf der offizielen Website vor möglichen Inkompatibilitäten gewarnt wird. Aber, wenn sowieso...

Wegen Sicherheits-Updates musst du aber keinen Backport-Kernel installieren - die fließen auch für den stabilen Zweig ein. Dort werden auch normale Fehler behoben, die keine sicherheitskritischen Aspekte haben. Allerdings müssen diese Fehler dann so gravierend sein, dass sie die Funktionaltität des Programms infrage stellen.

Klingt für mich eher so, als müsste ich mir in der Hinsicht zunächst keine Gedanken machen, sofern ich nicht zum Beispiel irgendwann mal andere Hardware verwenden möchte, für die Kernelfeatures benötigt werden, die im Kernel des Stable-Zweiges (noch) nicht implementiert sind. Aber, aktuell gehe ich einfach mal nicht davon aus.^^

[fireburner]

Imho, haben proposed-updates nichts mit Security Fixes zu tun.
In proposed-updates werden lediglich neuere Paketversionen geladen, die ohne proposed-updates erst beim nächsten Point Realease auf deinem System landen würden.

Für Sicherheitspatches ist jedoch das http://security.debian.org/debian-security stretch/updates main repository verantwortlich.
Dieses sollte immer (zusätzlich zum eigentlichen Debian Repo) eingebunden sein!

Proposed-updates wiederum sind optional und haben keinerlei Einfluss auf die Sicherheit.

siehe https://wiki.debian.org/StableProposedUpdates

[tobo]

Imho, haben proposed-updates nichts mit Security Fixes zu tun.
In proposed-updates werden lediglich neuere Paketversionen geladen, die ohne proposed-updates erst beim nächsten Point Realease auf deinem System landen würden.

Die Pakete von security.debian.org gehen zusätzlich direkt in den Proposed-Zweig rein, da stehen also nicht nur Point-Release-Updates drin. Aber inhaltlich hast du natürlich trotzdem recht, weil das ja nur eine zusätzliche Bezugsquelle ist, welche - entgegen dem was ich oben geschrieben habe - keinesfalls die Sache für Security-Updates beschleunigt.

[Animefreak79]

Für Sicherheitspatches ist jedoch das http://security.debian.org/debian-security stretch/updates main repository verantwortlich.
Dieses sollte immer (zusätzlich zum eigentlichen Debian Repo) eingebunden sein!

Das ist bei mir selbstverständlich der Fall. Die enstprechende Zeile in der sources.list war auch schon direkt nach der Installation vorhanden.