"Versionsfrage"

[tobiasd]

Hallo,

vorab es geht um folgenden Bug:

http://bugs.debian.org/606096

nun zu meiner Frage:

der aktuelle Debian Kernel ist ja laut http://packages.debian.org/squeeze/linu ... -2.6-amd64 Version 2.6.32+29. Bei den Abhängigkeiten steht unten linux-image-2.6.32-5-amd64.

Auf unserem Backup Server steht bei uname -r 2.6.32-5-amd64 und es gibt in den normalen Paketquellen keine neuere Version.

Die Version 2.6.32-5 ist also 2.6.32-29 und somit aktuell und der oben genannte Bug müsste gefixt sein, oder ? Bin gerade etwas confused

Grüße & vielen dank

Tobias

[Colttt]

also wenn die farbe grün ist, dann ist das gefixt

[tobiasd]

und 2.6.32-5 = 2.6.32+29?

[clue]

Hey, das ist lustig. Ich wollte grade nen eigenen Thread aufmachen wegen der Versionsnummerngeschichte.

Könnte mir mal bitte jemand erklären, warum wir eigentlich bei Kernelversion 2.6.32-34squeeze1 sind, wohingegen der Vanilla-Kernel schon bei 2.6.32-41 ist? Ich hab mir mal das changelog vom Debian Kernel angesehen. Dort kann ich zwar sehen, dass Patches sogar vom 2.6.32-39 im Debian-Kernel aufgenommen wurden. Was ich aber gar nicht verstehen kann, weswegen wir nicht komplett den neuen Kernel von Kernel.org übernehmen? Das ist doch der Longterm-stable-Kernel. Wenn da bugs wären, würden sie so schnell wie möglich gefixt werden. Also warum haben wir ihn dann nicht?

[deberik]

und 2.6.32-5 = 2.6.32+29?

Kurz: ja

Längere Erklärung: Das Paket linux-image-2.6-amd64 hat die Version 2.6.32+29. Der erste Teil (2.6.32) heißt, dass es vom neuesten (in den Archiven vorhandenen) Kernel der 2.6.32-Reihe abhängt. Der zweite Teil (+29) wird einfach bei jedem Upload (Fehlerbeseitigung, Abhängigkeit auf einen neueren 2.6.32er Kernel ...) um eins erhöht.

Könnte mir mal bitte jemand erklären, warum wir eigentlich bei Kernelversion 2.6.32-34squeeze1 sind, wohingegen der Vanilla-Kernel schon bei 2.6.32-41 ist?

Weil auch beim Kernel in Stable - wie bei jedem anderen Paket auch - normalerweise nur RC-Fehler beseitigt werden.

[clue]

Weil auch beim Kernel in Stable - wie bei jedem anderen Paket auch - normalerweise nur RC-Fehler beseitigt werden.

Ja aber der Witz am Longterm-Kernel ist doch grade, dass da nur Fehler beseitigt werden. Und falls noch zusätzliche Treiber/Verbesserungen reinkommen, sollten die doch auch rock-stable sein. Wo ist liegt denn sonst der Sinn im Longterm-Kernel?

[deberik]

Weil auch beim Kernel in Stable - wie bei jedem anderen Paket auch - normalerweise nur RC-Fehler beseitigt werden.

Ja aber der Witz am Longterm-Kernel ist doch grade, dass da nur Fehler beseitigt werden. Und falls noch zusätzliche Treiber/Verbesserungen reinkommen, sollten die doch auch rock-stable sein. Wo ist liegt denn sonst der Sinn im Longterm-Kernel?

Laut 624268 sind sich Debian-Entwickler nicht sicher, dass alle Longterm-Änderungen sinnvoll sind.
Und die kleinere Versionsnummer kommt wohl hauptsächlich dadurch zustande, dass immer mehrere Longterm-Veröffentlichungen in eine Debian-Aktualisierung einfließen (zuletzt 2.6.32.37, 2.6.32.38 und 2.6.32.39).

[clue]

Laut 624268 sind sich Debian-Entwickler nicht sicher, dass alle Longterm-Änderungen sinnvoll sind.

Hm ... wenn sie die nicht für sinnvoll halten, sollte sich das Debian-Kernel-Team mal mit den Leuten von Kernel.org unterhalten. Dann haben alle etwas davon.