Verständnisproblem: Was bedeutet bei Debian stable "Programme sind nicht aktuell"?

[porn()pole]

Hola,

der Titel sagt es schon, aber ich präzisiere:

Stable heisst ja, dass die installierten Programme ausgiebig getestet und für weitestgehend fehlerfrei angesehen werden. Wenn man nun eines dieser Programme per apt-get install XY auf die neueste Version bringt - was heisst das dann für die stable-Version? Bedient sich diese generell nur in einem stable-repository oder kann ich eine stable-Version installieren und dann dennoch punktuell einzelne Programme auf den neuesten (wenn auch möglicherweise nicht fehlerfreien) Stand bringen?

Wie ist in diesem Zusammenhang dann der rolling release von testing zu verstehen? Wenn man die stable permanent händisch auf den neuesten Stand bringt, dann ist diese ja auch quasi rolling ... oder?

 

[powerfx]

stable bietet von sich aus auch nur stable-Updates an. Wenn du ein Repo hinzufügst/änderst, so dass auch andere Updates installiert werden, ist es nicht mehr "stable". Das stimmt, ja.

 

[HominiLupus]

Du kannst Backports entweder selber erstellen, oder vom Debian Backports Repo installieren. Dann hast du neuere Programme in einem älteren Debian System ohne daß du ein "Frankendebian" hast.
http://backports.debian.org/

 

[Tumbleweed]

Im Normalfall bedient sich apt nur aus einem repository (sind natürlich mehrere aber ich meine ein "Level" wie stable/testing/unstable/experimental). Man kann mischen, es wird aber davon abgeraten, weil dadurch ungetestete Konstellationen entstehen.

Stable bedeutet erst einmal nur, dass sich die Version nicht oft ändert. Wenn Updates kommen, sind es in der Regel wichtige Patches (Sicherheit, Crash-Fixes usw.).

Du hast immer die Option an der Paketverwaltung vorbei selbst Sachen zu installieren, sei es mit heruntergeladenen binaries oder selbst kompiliert. Ungewöhnlich ist das nicht, aber es braucht etwas Disziplin, weil du an der natürlichen Organisation von Debian vorbei arbeitest und "Verschmutzung" produzierst. Solche händischen Installationen updaten sich meist nicht selbst, d.h. sie bekommen auch keine Sicherheitsupdates usw.

Stable wird nur alle paar Jahre mal "wirklich" geupdated. Allerdings sind die Versionen die dann reinfließen auch nicht gerade bleeding edge. Ich arbeite produktiv (zu Hause und auf Arbeit) mit testing und kann nicht von großen Problemen berichten. Aber man sollte das natürlich nur tun, wenn man im Fall dass etwas passiert, sich auch zu helfen weiß bzw. googeln kann.

Ja, in testing gibt es manchmal bugs (z.B. ging Skype mal eine Woche nicht bei mir), aber das ist für mich verschmerzbar, denn oft gibt es workarounds oder man downgraded eben. Ich update z.B. immer erst zu Hause und wenn es grob rund läuft, ziehe ich auf Arbeit nach.

Vorteil ist, dass testing eben sehr aktuell ist und neben bugs auch bugfixes schneller dort ankommen.

 

[HominiLupus]

Testing hat keine Security Updates, nur stable hat diese garantiert.
Man kann nicht mischen weil dann niemand, wirklich niemand "will support this mess". -> Frankendebian.

 

[Tumbleweed]

Testing hat keine Security Updates, nur stable hat diese garantiert.

Was meinst du damit? Warum sollte ein security fix an testing vorbei nur in stable eingepflegt werden? Andersherum wird ein Schuh draus - einzig und allein auf security updates kann man sich in stable verlassen. Alles andere ist Hoffen auf backports.

 

[porn()pole]

Hintergrund meiner Frage:

Habe derzeit xubuntu am Laufen, ist auch alles soweit okay und verständlich, die Foren von ubuntuusers sind wirklich extrem hilfreich.

ABER: irgendwie hat systemd und einige abhängige Dinge immer wieder Probleme beim Booten. Deswegen wollte ich (ohnehin mal ursprünglich) auf Debian stable setzen.

Ich brauche nicht wirklich viel für ein für mich funktionierendes System und muss nicht alles topaktuell haben. Aber einige Programme, die ich brauche (z.B. jdownloader) gibt es ohnehin nicht in den offiziellen Repos. Von daher versuche ich eben hier anzufühlen, ob ich eher stable oder testing brauche.

Nur so der Vollständigkeit halber ... die Geschichte mit den Backports ist mir zum Beispiel komplett neu! Danke für den Hinweis!

 

[HominiLupus]

Weil unstable und testing noch nie security fixes bekommen haben.

unstable bekommt neue Pakete (inkl. Fix) und es dauert dann noch eine Weile bis testing security fixes bekommt. Testing war, von der security her, schon immer sehr benachteiligt.

A: Security for unstable is primarily handled by package maintainers, not by the Debian Security Team. Although the security team may upload high-urgency security-only fixes when maintainers are noticed to be inactive, support for stable will always have priority. If you want to have a secure (and stable) server you are strongly encouraged to stay with stable.

"Security for testing benefits from the security efforts of the entire project for unstable. However, there is a minimum two-day migration delay, and sometimes security fixes can be held up by transitions. The Security Team helps to move along those transitions holding back important security uploads, but this is not always possible and delays may occur. Especially in the months after a new stable release, when many new versions are uploaded to unstable, security fixes for testing may lag behind. If you want to have a secure (and stable) server you are strongly encouraged to stay with stable."

Ergo: es gibt keine Security für unstable (hats noch nie gegeben) und es gibt noch schlechtere für testing.


@TE: jdownloader ist problemlos: das braucht Java und wird dann ausserhalb des Paketsystems installiert. Andere Dinge sind schwieriger. Also wenn du z.B. ein komplettes neues kde/gnome/xfce brauchst, ist stable plus backports nichts für dich. Wenn du einen neuen Kernel oder auch mal ein neues X oder Treiber wegen neuer Hardware brauchst, dann sind backports eine gute Wahl. Je größer die Pakete mit vielen komischen Abhängigkeiten, also eben gnome oder so was, desto schwerer funktioniert es mit Backports.

Auch debian stable nutzt systemd.

 

[Tumbleweed]

@HominiLupus: Okay da hast du wohl recht. Habe gerade mal zur aktuellen OpenSSH-Client-Lücke gesucht (CVE-2016-0777)

jessie    1:6.7p1-5    vulnerable
jessie (security)    1:6.7p1-5+deb8u1    fixed
stretch    1:7.1p1-6    vulnerable
sid    1:7.1p2-1    fixed

Für Server würde ich aber auch nicht auf die Idee kommen testing zu benutzen/empfehlen. Für Clients ist es für mich zu verschmerzen. Immer noch schneller als bei so manch anderem OS.

Noch zu stable und eigene Installationen: man ist beim Kompilieren neuerer Versionen nicht ganz uneingeschränkt. Ich habe z.B. am Ende von wheezy stable nicht mehr lyx kompiliert bekommen, weil Abhängigkeiten (libc usw.) zu alt waren. Die meiste Zeit über ist stable schon okay, nur gegen Ende hin, bekommt man eben gern mal solche Problemchen.

 

[porn()pole]

Darf ich also zusammenfassen:

Stable = Server und sehr konventionell benutzte Clients
Testing = Clients, an denen ab und an ein wenig rumprobiert werden soll, die aber nie wirklich sicherheitsrelevant werden ..

right?

Ergo: ich nehme testing.