Wie kann ich sehen, ob ich die LTS version habe?

[DaCoda]

Code: Alles auswählen

lsb_release -a

zeigt das an:

user1@debian:~$ lsb_release -a
No LSB modules are available.
Distributor ID: Debian
Description: Debian GNU/Linux 10 (buster)
Release: 10
Codename: buster

Wie kann ich aber sehen ob ich die LTS version nutze? Würde das da stehen?

[tobo]

Du benutzt Buster und Buster ist "die" LTS:
https://wiki.debian.org/LTS

[uname]

Wichtig ist ja vor allen, dass du die Updates erhälst. Hierfür musstest du aber beim (automatischen) Wechsel zu LTS nichts an den Paketquellen ändern.

Schau evtl. die korrekten Paketquellen hier: https://wiki.debian.org/LTS

Du solltest trotzdem darüber nachdenken irgendwann von Buster auf Bullseye zu wechseln.
LTS-Versionen sind nicht dafür gedacht ein Release wie z. B. Bullseye zu überspringen.

[Meillo]

LTS bei Debian ist etwas anderes als LTS bei Ubuntu.

[uname]

LTS bei Debian ist etwas anderes als LTS bei Ubuntu.

Das stimmt. Wobei nach Ubuntu wurde ja auch nicht gefragt.
Bei Ubuntu ist LTS das Standard-Release. Bei Debian ist LTS die Verlängerung des Standard-Support-Zeitraums nach OldStable.

Offtopic Ubuntu
Ubuntu bzw. Canonical kommunziert deren Releases vollkommen falsch.
Es gibt LTS-Versionen, die man produktiv einsezten sollte (inkl. Desktop).
Der Support ist 5 Jahre bzw. 10 Jahre.

Und dann gibt es noch diese grauen Balken. Die Länge des Balkens ist der Supportzeitraum.
Viele vor allen Einsteiger verstehen nicht, dass diese Releases für sie gar nicht gedacht sind.
Gleichzeitig beschweren sie sich, dass sie dauernd die Releses aktualisieren müssen oder das Release nicht mehr unterstützt wird.
Also falls hier jemand Ubuntu nutzt: Finger weg von Nicht-LTS-Releases und immer nur bei LTS-Releases alles zwei Jahre upgraden.
Auch keinesfalls von Ubuntu 22.04 LTS dann auf 22.10 umsteigen. Warten bis 24.04 LTS und gut ist es.
Wer immer neue Features benötigt, darf über diese Zwischenreleases nachdenken oder besser gleich zu Debian Testing/Sid wechseln.


Quelle: https://ubuntu.com/about/release-cycle

[Meillo]

LTS bei Debian ist etwas anderes als LTS bei Ubuntu.

Das stimmt. Wobei nach Ubuntu wurde ja auch nicht gefragt.

Da hast du recht, es war nur die Formulierung der Frage, die das Verstaendnis von LTS im Sinne von Ubuntu nahegelegt hat. Fuer Debian macht die Frage -- ob man eine LTS-Version hat -- keinen Sinn, weil bei Debian LTS etwas anderes bedeutet und nicht manche Versionen LTS haben und andere nicht.

Wie du richtig geschrieben hast:

Bei Ubuntu ist LTS das Standard-Release. Bei Debian ist LTS die Verlängerung des Standard-Support-Zeitraums nach OldStable.

[DaCoda]

Du benutzt Buster und Buster ist "die" LTS:
https://wiki.debian.org/LTS

Danke, ich glaube jetzt habe ich verstanden.

Mal angenommen ich installiere mir heute unstable (Sid).

Dann wird meine Installation irgendwann automatisch zu testing, dann stable und dann unstable.

Ohne dass ich etwas mache. Während der code name "Sid" gleich bleibt.
Ist das richtig?

[Meillo]

Mal angenommen ich installiere mir heute unstable (Sid).

Dann wird meine Installation irgendwann automatisch zu testing, dann stable und dann unstable.

Ohne dass ich etwas mache. Während der code name "Sid" gleich bleibt.
Ist das richtig?

Die Installation bleibt immer das was du in die sources.list eintraegst.

Wenn du dort einen Zustandsnamen (unstable/testing/stable) eintraegst, dann bleibt sie immer in dem Zustand, auch wenn das Release zwischendurch wechselt. Wenn du also stable hast und ein neues Release rauskommt, dann wird dein System darauf upgegradet, damit du dann wiederum stable hast.

Wenn du einen Releasenamen (buster/bullseye/...) eintraegst, dann bleibt deine Installation immer das Release und wechselt mit ihm durch die Zustaende (unstable/testing/stable/oldstable/...).

Du hast die Wahl welche der zwei Varianten dir lieber ist.


(Btw: Sid ist ein Sonderfall was die Bezeichnung angeht, weil das zwar ein Releasename ist, der aber immer unstable bleibt.)

[MSfree]

Mal angenommen ich installiere mir heute unstable (Sid).
Dann wird meine Installation irgendwann automatisch zu testing, dann stable und dann unstable.

Nein, SID ist ein Sonderfall, Still In Developement ist und bleibt immer SID.

Wenn du heute Bookworm installierst, dann ist das im Moment noch testing. Nach dem Release wird es zu stable und schließlich zu oldstable, oldoldstable..., und spätestens mit oldstable bist du im LTS-Modus.

testing, stable, oldstable oldoldstable... sind letztlich nur symbolische Links im Repository, die immer auf einen Releasenamen zeigen. Zur Zeit:
testing -> bookworm
stable -> bullseye
oldstable -> buster
oldoldstable -> stretch
oldoldoldstable -> jessie

Wenn Bookworm released ist, ändert sich die Verlinkung wie folgt:
testing -> trixie
stable -> bookworm
oldstable -> bullseye
oldoldstable -> buster
oldoldoldstable -> stretch
Jessie wird nach archive.debian.org verschoben und verschwindet damit vom Radar.

Wenn du in deine sources.list stable einträgst, wirst du mit einem dist-upgrade automatisch auf das nächste Release hochgezogen, sobald es verfügbar ist. Vorteil: immer die aktuelle "stable". Nachteil, es werden immer auch Softwarepakete entfernt. Wenn man ein betroffenes Paket im Einsatz hat, muß man mit Problemen rechnen oder alternative Pakete suchen. Bekannte Beipiele aus der Vergangenheit: mysql wurde durch mariadb ersetzt, SysV-Init wurde durch systemd ersetzt.

Wenn du in deine sources.list einen Releasenamen einträgst, bist du darauf festgenagelt (es sei denn, du änderst den). Vorteil: keine Überraschungen mit plötzlich nicht mehr vorhandenen Paketen. Nachteil, irgendwann stehst du mit einer nicht mehr gewarteten Version da.

Sorry Meillo, da haben sich unsere Posts überschnitten.

[Meillo]

Sorry Meillo, da haben sich unsere Posts überschnitten.

Doppelt haelt besser. Ausserdem hast du es ausfuehrlicher und anschaulicher erklaert.

[tijuca]

Nein, SID ist ein Sonderfall, Still In Developement ist und bleibt immer SID.

Dann ist testing ebenfalls ein Sonderfall? Und stable bzw. oldstable auch?

Es geht darum was er Anwender in seine sources.list einträgt und nicht um das was das Release Team auf den Master Spiegelservern.

Alle diese Installationen, sofern man dieses Releasenamen benutzt, werden immer in diesem Zustand verbleiben die den aktuellen Paketzuständen jeweils entsprechen.

[Meillo]

Nein, SID ist ein Sonderfall, Still In Developement ist und bleibt immer SID.

Dann ist testing ebenfalls ein Sonderfall? Und stable bzw. oldstable auch?

Es geht darum was er Anwender in seine sources.list einträgt und nicht um das was das Release Team auf den Master Spiegelservern.

Wie ich oben beschrieben habe, kann man sich aussuchen, ob man Releasenamen (wie buster und bullseye) verwendet und dann diese Version ueber alle Lebenszykluszustaende verfolgt, oder ob man Zustands-/Lebenszyklusnamen (wie unstable und stable) verwendet und bei diesem Zustand bleibt, auch wenn die Releaseversion sich aendert. Man kann immer nur eines fix machen (indem man es in die sources.list eintraegt), das andere ist dann variabel. Welches von beiden man fix haben will haengt davon ab welches Verhalten man haben will.


Der Sonderfall von sid ist, dass sid ein ``Releasename'' ist (wie alle Toy Story Namen). Der Zustandsname von sid ist unstable. Im Gegensatz zu den anderen Releasenamen aendert sich das bei sid aber nicht. Sid bleibt immer unstable.

[dasebastian]

Aus dem Debianwiki zum Thema sources.list:

The 'distribution' can be either the release code name / alias ( stretch, buster, bullseye, bookworm, sid) or the release class (oldoldstable, oldstable, stable, testing, unstable) respectively. If you mean to be tracking a release class then use the class name, if you want to track a Debian point release, use the code name. Avoid using stable in your sources.list as that results in nasty surprises and broken systems when the next release is made; upgrading to a new release should be a deliberate, careful action and editing a file once every two years is not a burden.

Habt ihr schon schön aufgedröselt, ich wollte nur noch mal die offizielle Erklärung nachreichen.

[Meillo]

Habt ihr schon schön aufgedröselt, ich wollte nur noch mal die offizielle Erklärung nachreichen.

[cosinus]

upgrading to a new release should be a deliberate, careful action and editing a file once every two years is not a burden.

Wieso gibt es diese Möglichkeit in der sources.list überhaupt wenn das so gefährlich und auch sinnfrei ist? Abgesehen von sid/unstable und testing, wer diesen Kanal nimmt, sollte ja schon ziemlich genau wissen was er da tut. Ich habe zwar auch testing, aber nur auf meinen Desktops zu Hause und der (eher unwichtigen) Client-Kiste im Büro. Für nen Server würde ich nur das aktuelle stable nehmen aber nicht 'stable' explizit in die sources.list schreiben - macht das wer und warum?!

[Meillo]

upgrading to a new release should be a deliberate, careful action and editing a file once every two years is not a burden.

Wieso gibt es diese Möglichkeit in der sources.list überhaupt wenn das so gefährlich und auch sinnfrei ist? Abgesehen von sid/unstable und testing, wer diesen Kanal nimmt, sollte ja schon ziemlich genau wissen was er da tut. Ich habe zwar auch testing, aber nur auf meinen Desktops zu Hause und der (eher unwichtigen) Client-Kiste im Büro. Für nen Server würde ich nur das aktuelle stable nehmen aber nicht 'stable' explizit in die sources.list schreiben - macht das wer und warum?!

Wenn man weiss wie Upgrades funktionieren und man debian-devel-announce liest, dann sehe ich keinen Grund warum man auf einem Desktop-System nicht ``stable'' in die sources.list eintragen sollte. Ich empfehle es nicht aber wer will soll das machen. Es werden nach einem neuen Release ja nicht automatisch Pakete entfernt, sondern apt-get schreibt hin was es tun will und man bestaetigt oder bricht ab. Das ist auch nicht anders wie wenn man testing nutzt. Wenn es fuer testing in Ordnung ist, warum soll es dann fuer stable nicht auch in Ordnung sein?

Die Einstellung ist weder gefaehrlich noch sinnfrei, weil man damit eben genau das haben kann: ein System, das immer stable bleibt. Die Einstellung kann vor allem irritierend sein, weil dann beim Releasewechsel sich ploetzlich eine ganze Menge aendert und ggf. Pakete entfernt werden.

Ich denke es geht darum was du auch schreibst: Wenn jemand unstable oder testing einstellt, dann weiss die Person im Normalfall was sie tut. Wenn jemand stable einstellt, dann weiss sie es eher nicht und denkt sich dass das viel bequemer waere. Darauf zielt IMO dieser Hinweis ab: Unerfahrene sollten nicht stable in die sources.list schreiben.

[cosinus]

Aber warum kommt dann so ein Hinweis:

... and editing a file once every two years is not a burden.

[Meillo]

Aber warum kommt dann so ein Hinweis:

... and editing a file once every two years is not a burden.

Das soll halt dazu motivieren, den Weg ueber Releasenamen zu nehmen.

Ich denke eigentlich schon, dass es eine Huerde oder Belastung ist, denn ein unerfahrener User hat doch nach zwei Jahren laengst vergessen wie die Datei heisst und dass sie unter /etc/apt/sources.list zu finden ist. Ich habe damals auch einige Zeit gebraucht bis ich mir diesen Pfad merken habe koennen. Wenn man die Datei jeden Monat aendern muesste, dann wuesste man zumindest den Pfad auswendig.

Wichtiger jedoch ist, dass Releasewechsel ja nicht so oft vorkommen und man diese dann aktiv angehen sollte. Da kann man dann auch nochmal in den Releasenotes oder im Anwenderhandbuch nachlesen oder einfach im Web nach einer Anleitung suchen. Dafuer alle zwei Jahre zwei Stunden zu investieren sollte nicht zu viel Aufwand sein.

[fischig]

Aber warum kommt dann so ein Hinweis:

Das bezieht nach meiner Erkenntnis sich auf die Verwendung des Code-Namens in der sources.list, und behauptet, dass es ja kein allzu großes Problem darstellt ca. alle zwei Jahre diesen Code-Namen BEWUSST zu ändern. Macht man's anders herum, hat aber keine Lust, sich um die von Meillo exakt genannten Bedingungen SORGFÄLTIG zu kümmern - wir brauchen da gar nicht von erfahren oder unerfahren zu reden - dann kann man halt böse auf die Nase fallen.

Wo ist das Problem?

[cosinus]

Wo ist das Problem?

Ich seh da kein Problem. Nur einen Widerspruch. Weil es ja kein Aufwand ist, alle zwei Jahre mal den Namen des release zu ändern.

[Meillo]

Wo ist das Problem?

Ich seh da kein Problem. Nur einen Widerspruch. Weil es ja kein Aufwand ist, alle zwei Jahre mal den Namen des release zu ändern.

Ach so meinst du das. Nun, vermutlich ist es ein Argument derjenigen, die lieber ``stable'' eintragen, dass sie dann die Datei nie mehr anfassen muessen.

[tobo]

Wo ist das Problem?

Ich seh da kein Problem. Nur einen Widerspruch. Weil es ja kein Aufwand ist, alle zwei Jahre mal den Namen des release zu ändern.

Nur den Versionsnamen zu ändern und dann die Aktualisierung über APT update/dist-upgrade zu machen, wäre aber gleichbedeutend. Das war noch nie und wird vermutlich auch nie die vorgeschlagene Aktualisierungslösung sein, wobei sie aber durchaus funktionieren kann. Empfohlen wird häufig eine 2-stufige Aktualisierung und auch ein besonderes Augenmerk auf spezielle Quellen oder andere Besonderheiten. Beim direkten Hochheben fällen ja alle Sicherheitsvorschläge unter den Tisch...

[cosinus]

Nur den Versionsnamen zu ändern und dann die Aktualisierung über APT update/dist-upgrade zu machen, wäre aber gleichbedeutend. Das war noch nie und wird vermutlich auch nie die vorgeschlagene Aktualisierungslösung sein, wobei sie aber durchaus funktionieren kann. Empfohlen wird häufig eine 2-stufige Aktualisierung und auch ein besonderes Augenmerk auf spezielle Quellen oder andere Besonderheiten. Beim direkten Hochheben fällen ja alle Sicherheitsvorschläge unter den Tisch...

Verstehe jetzt nicht was du meinst. Wie machst du denn ein dist-upgrade zB von buster nach bullseye?

[rhHeini]

Wo ist das Problem?

Ich seh da kein Problem. Nur einen Widerspruch. Weil es ja kein Aufwand ist, alle zwei Jahre mal den Namen des release zu ändern.

Ach so meinst du das. Nun, vermutlich ist es ein Argument derjenigen, die lieber ``stable'' eintragen, dass sie dann die Datei nie mehr anfassen muessen.

Und die überwiegende Mehrzahl dieser Anwender kriegen dann den Wechsel bzw. dessen Ankündigung nicht mit und stehen plötzlich vor Problemen auf die sie nicht vorbereitet sind. IMHO sind die Release-Namen die sichere Option für die meisten Anwender.

[tobo]

Nur den Versionsnamen zu ändern und dann die Aktualisierung über APT update/dist-upgrade zu machen, wäre aber gleichbedeutend. Das war noch nie und wird vermutlich auch nie die vorgeschlagene Aktualisierungslösung sein, wobei sie aber durchaus funktionieren kann. Empfohlen wird häufig eine 2-stufige Aktualisierung und auch ein besonderes Augenmerk auf spezielle Quellen oder andere Besonderheiten. Beim direkten Hochheben fällen ja alle Sicherheitsvorschläge unter den Tisch...

Verstehe jetzt nicht was du meinst. Wie machst du denn ein dist-upgrade zB von buster nach bullseye?

Naja, ich schaue mir erstmal die Release Notes dazu an:
https://www.debian.org/releases/bullsey ... ase-notes/
In Kapitel 4 sind dann ja einige Stolperstellen aufgeführt. Ok, das meiste ist bestimmt zu vernachlässigen bzw. irrelevant, aber z.B. die zweistufige Aktualisierung (update/upgrade/dist-upgrade) steht bestimmt nicht nur da, weil noch Platz im Internet war. Auf einigen Maschinen hat das bestimmt Bewandtnis und selbst wenn es nur die theoretische Möglichkeiten eines Scheiterns verringert, ist das ein Punkt. Andernfalls gibt es ja keinen Unterschied zwischen den beiden Vorgehensweisen, mit Ausnahme, dass man den Namen noch ändert, bevor man aktualisiert.