Stable vs Testing

Warum Debian? Was muss ich vorher wissen? Wo geht's nach der Installation weiter?
Trollkirsche
Beiträge: 446
Registriert: 08.08.2015 15:03:09
Wohnort: Schweiz

Stable vs Testing

Beitrag von Trollkirsche » 13.04.2019 23:53:58

Hallo zusammen,

Wie verhält es sich mit einer Testing Version, die man installiert? Wird eine Testing Version stetig weitergeführt und geht dann, nachdem eine neue Stable Version erscheint, in die nächste Version über oder bleibt sie diesselbe Version, in diesem Falle die Buster Version? Wird dann Testing zu Stable und man müsste sich die neue Testing Version installieren, die dann erscheint, damit man die neue Version geniessen kann?

TomL
Beiträge: 5203
Registriert: 24.07.2014 10:56:59

Re: Stable vs Testing

Beitrag von TomL » 13.04.2019 23:57:21

Trollkirsche hat geschrieben: ↑ zum Beitrag ↑
13.04.2019 23:53:58
Wie verhält es sich mit einer Testing Version, die man installiert? Wird eine Testing Version stetig weitergeführt und geht dann, nachdem eine neue Stable Version erscheint, in die nächste Version über oder bleibt sie diesselbe Version, in diesem Falle die Buster Version?
In meinen sources.lists steht nirgends testing drin, sondern von Anfang an Buster. Das heisst, meine Installationen sind jetzt schon Buster und bleiben immer Buster. Würde ich testing eintragen, bleiben sie Buster nur bis zum Release von Buster.... ab dem Tag wird Testing dann sukzessive zu Bullseye.
vg, Thomas

Trollkirsche
Beiträge: 446
Registriert: 08.08.2015 15:03:09
Wohnort: Schweiz

Re: Stable vs Testing

Beitrag von Trollkirsche » 14.04.2019 00:04:58

TomL hat geschrieben: ↑ zum Beitrag ↑
13.04.2019 23:57:21
Trollkirsche hat geschrieben: ↑ zum Beitrag ↑
13.04.2019 23:53:58
Wie verhält es sich mit einer Testing Version, die man installiert? Wird eine Testing Version stetig weitergeführt und geht dann, nachdem eine neue Stable Version erscheint, in die nächste Version über oder bleibt sie diesselbe Version, in diesem Falle die Buster Version?
In meinen sources.lists steht nirgends testing drin, sondern von Anfang an Buster. Das heisst, meine Installationen sind jetzt schon Buster und bleiben immer Buster. Würde ich testing eintragen, bleiben sie Buster nur bis zum Release von Buster.... ab dem Tag wird Testing dann sukzessive zu Bullseye.
Interessant. Kann ich gefahrlos eine Stretch Version zu einer Testing Version Buster upgraden oder muss ich das System neu installieren? Ein host läuft bereits auf Buster Testing und möchte nun auch den anderen PC, auf dem eine stretch stable version läuft, auf buster testing migrieren.

MSfree
Beiträge: 6045
Registriert: 25.09.2007 19:59:30

Re: Stable vs Testing

Beitrag von MSfree » 14.04.2019 00:29:56

Trollkirsche hat geschrieben: ↑ zum Beitrag ↑
14.04.2019 00:04:58
Kann ich gefahrlos eine Stretch Version zu einer Testing Version Buster upgraden oder muss ich das System neu installieren?
Gefahrlos ist nichts im Leben. Backups von Nutzerdaten und den wichtigsten Konfiurationsdateien sollte man immer vorher anlegen.

Von Stretch auf Buster sollte ziemlich schmerzfrei ablaufen und eine Neuinstallation ist nicht nötig.

Trollkirsche
Beiträge: 446
Registriert: 08.08.2015 15:03:09
Wohnort: Schweiz

Re: Stable vs Testing

Beitrag von Trollkirsche » 14.04.2019 00:47:08

MSfree hat geschrieben: ↑ zum Beitrag ↑
14.04.2019 00:29:56
Trollkirsche hat geschrieben: ↑ zum Beitrag ↑
14.04.2019 00:04:58
Kann ich gefahrlos eine Stretch Version zu einer Testing Version Buster upgraden oder muss ich das System neu installieren?
Gefahrlos ist nichts im Leben. Backups von Nutzerdaten und den wichtigsten Konfiurationsdateien sollte man immer vorher anlegen.

Von Stretch auf Buster sollte ziemlich schmerzfrei ablaufen und eine Neuinstallation ist nicht nötig.
MSfree hat geschrieben:Gefahrlos ist nichts im Leben.
Du sagst es :P

Backups des home, etc, root verzeichnisses mache ich immer vor grösseren operationen am System.

Kann ich eigentlich auch nach Upgrade von einem zum anderen System komplett das ganze home dir übernehmen? Bisher habe ich immer, um ein sauberes System zu erhalten, jedes Verzeichnis das ich migrieren wollte, auf das neue System vom Backup übernommen.

Damit steigt jedoch auch gleichzeitig die Fehlerquote und man könnte das ein oder andere vergessen, rüberzukopieren. Andererseits möchte ich keine Altlasten des home verzeichnisses auf das neue System übernehmen. Gleiches gilt für das verzeichnis etc.

Wie migriert ihr eure systemdaten so von einer Version zur anderen?

Benutzeravatar
willy4711
Beiträge: 4041
Registriert: 08.09.2018 16:51:16

Re: Stable vs Testing

Beitrag von willy4711 » 14.04.2019 07:39:39

Trollkirsche hat geschrieben: ↑ zum Beitrag ↑
14.04.2019 00:47:08
Kann ich eigentlich auch nach Upgrade von einem zum anderen System komplett das ganze home dir übernehmen? Bisher habe ich immer, um ein sauberes System zu erhalten, jedes Verzeichnis das ich migrieren wollte, auf das neue System vom Backup übernommen.
Das ist an sich ein ganz gutes Vorgehen., muss aber nun nicht unbedingt nach einem Upgrade gemacht werden.

Ich mache es so, dass ich von Zeit zu Zeit die Verzeichnisse durchgehe und Konfigurationsdateien / Verzeichnisse von Programmen, die nicht mehr vorhanden sind, lösche. Das sind aber immer nur die für mich oder den jeweiligen Nutzer angelegten Konfigs.

System-weit sind diese Dateien in der Regel in /etc. Nur dort werden sie auch bei einem Upgrade überschrieben. Deshalb kann es sinnvoll sein, auch dieses Verzeichnis zu sichern, wenn man dort systemweite Veränderungen vorgenommen hat.

Das Root- Verzeichnis sichere ich nie. Wenn man da wirklich etwas zerschossen hat (ist mir in den ganzen Jahren erst einmal passiert), ist der Aufwand, einen Fehler zu finden, in der Regel um ein Vielfaches größer, als eine Neuinstallation.

Was ich noch sichere ist mein /opt. Diese Verzeichnis ist bei mir komplett von einem System zu einem beliebigen anderen übertragbar. Da dort nur Programme sind, die sich ohne weitere Installation starten lassen ( also Firefox , Thunderbird, FreeFileSync, Master-PDF-Editor usw).
Die Desktop-Dateien für diese Programme befinden sich eh in meinem /home, sind also nach einer eventuellen Neuinstallation
sofort wieder verfügbar. Ich portiere das /opt sogar in VM's, wenn ich die Programme dort brauche.

Nochmal zu den Releases:

Ich habe mich noch zu Jessies Zeiten entschieden, in meiner sources.list ausschließlich Testing zu haben.
Vorteil: Man hat quasi ein "rolling Release".
Bei einem Release - Wechsel geht es im gewohnten täglichen "full-upgrade" Modus weiter wie immer bei Testing.
Das ist ein Klick auf einen Starterund gut ist.

Ernsthafte Probleme habe ich die ganzen Zeit nur einmal gehabt. Aber wenn ich sehe was Nutzer teilweise für Probleme mit der
Stable Version haben, fahre ich damit sehr gut. Abgesehen von ein bisschen mehr Upgrade - Arbeit. :mrgreen:

Wenn man sich entscheidet, Testing zu fahren sollte man das berücksichtigen, genauso wie die Möglichkeit, dass es mal Probleme geben kann.

miwie
Beiträge: 76
Registriert: 10.07.2002 08:59:23
Kontaktdaten:

Re: Stable vs Testing

Beitrag von miwie » 14.04.2019 09:49:58

Also ich fahre schon seit Jahren durchgehend "testing".
Zugegeben gibt es ab und an kleinere Probleme, aber ich will es nicht mehr missen.

Trollkirsche
Beiträge: 446
Registriert: 08.08.2015 15:03:09
Wohnort: Schweiz

Re: Stable vs Testing

Beitrag von Trollkirsche » 14.04.2019 10:07:39

Trollkirsche hat geschrieben: ↑ zum Beitrag ↑
14.04.2019 00:47:08
Kann ich eigentlich auch nach Upgrade von einem zum anderen System komplett das ganze home dir übernehmen? Bisher habe ich immer, um ein sauberes System zu erhalten, jedes Verzeichnis das ich migrieren wollte, auf das neue System vom Backup übernommen.
willy4711 hat geschrieben:Das ist an sich ein ganz gutes Vorgehen., muss aber nun nicht unbedingt nach einem Upgrade gemacht werden.
Ja, da ich zurzeit immer das ganze OS neu installiert habe, war zur übernahme der Daten dies leider unumgänglich. Bei einem Upgrade sollte das sichern der Daten genügen, die sind ja nacher immer noch da.
willy4711 hat geschrieben:Ich mache es so, dass ich von Zeit zu Zeit die Verzeichnisse durchgehe und Konfigurationsdateien / Verzeichnisse von Programmen, die nicht mehr vorhanden sind, lösche. Das sind aber immer nur die für mich oder den jeweiligen Nutzer angelegten Konfigs.
Klingt gut. Ansonten immer noch lieber ein paar Altlasten als aus Versehen mal die zertifikate vergessen...
willy4711 hat geschrieben:System-weit sind diese Dateien in der Regel in /etc. Nur dort werden sie auch bei einem Upgrade überschrieben. Deshalb kann es sinnvoll sein, auch dieses Verzeichnis zu sichern, wenn man dort systemweite Veränderungen vorgenommen hat.
Beissen sich die config Dateien nicht beim Release einer neuen Version? Es kann ja sein das dann Programme über eine andere configdatei gesteuert werden, die jedoch dann gleich hiesse? Oder bleiben die Dateien in /etc in jedem Falle immer gleich?
willy4711 hat geschrieben:Das Root- Verzeichnis sichere ich nie. Wenn man da wirklich etwas zerschossen hat (ist mir in den ganzen Jahren erst einmal passiert), ist der Aufwand, einen Fehler zu finden, in der Regel um ein Vielfaches größer, als eine Neuinstallation.
Ich hab im root verzeichnis paar scripte zur Automatisierung der backups per rsync. Diese möchte ich in jedem Falle mitsichern. Es geht mir also weniger um die einstellungen des Benutzers root als um die scripte, die von root aus gestartet werden und sich in dem verzeichnis befinden.
willy4711 hat geschrieben:Was ich noch sichere ist mein /opt. Diese Verzeichnis ist bei mir komplett von einem System zu einem beliebigen anderen übertragbar. Da dort nur Programme sind, die sich ohne weitere Installation starten lassen ( also Firefox , Thunderbird, FreeFileSync, Master-PDF-Editor usw).
Die Desktop-Dateien für diese Programme befinden sich eh in meinem /home, sind also nach einer eventuellen Neuinstallation
sofort wieder verfügbar. Ich portiere das /opt sogar in VM's, wenn ich die Programme dort brauche.
Gute Idee.
willy4711 hat geschrieben:Nochmal zu den Releases:

Ich habe mich noch zu Jessies Zeiten entschieden, in meiner sources.list ausschließlich Testing zu haben.
Vorteil: Man hat quasi ein "rolling Release".
Bei einem Release - Wechsel geht es im gewohnten täglichen "full-upgrade" Modus weiter wie immer bei Testing.
Das ist ein Klick auf einen Starterund gut ist.

Ernsthafte Probleme habe ich die ganzen Zeit nur einmal gehabt. Aber wenn ich sehe was Nutzer teilweise für Probleme mit der
Stable Version haben, fahre ich damit sehr gut. Abgesehen von ein bisschen mehr Upgrade - Arbeit. :mrgreen:

Wenn man sich entscheidet, Testing zu fahren sollte man das berücksichtigen, genauso wie die Möglichkeit, dass es mal Probleme geben kann.
Hast du irgendeine gute Anleitung oder weitergehende Tipps, wie ich so ein Update vollziehen kann?
Muss ich in der sources.list dann die Einträge zb von:

deb http://ftp.debian.org/debian/ stretch main

zu

deb http://ftp.debian.org/debian/ testing main

ersetzen?

Welche weiteren Schritte sind ansonsten noch notwendig?

Vielen Dank schonmal für die Hilfe!

guennid

Re: Stable vs Testing

Beitrag von guennid » 14.04.2019 12:21:32

Ich schätze, das ist mit einiger Sicherheit nicht der komplette Inhalt deiner sources.list (mal ganz abgesehen vom möglichen Inhalt von /etc/apt/sources.list.d) und ohne den zu kennen, macht es wenig Sinn, mehr als das bereits Gesagte zu sagen.

Vielleicht eins noch: Entscheide dich, ob du entweder die Begriffe stable und testing oder die jeweiligen alias-Begriffe in der sources.list nutzen willst. Letzteres schützt alle außer willy vor unliebsamen Überraschungen, aber der weiß auch, was er tut. :wink:

Durch heftiges Nachdenken über Release-Wechsel sollte es sich aber auch jedem anderen offenbaren.

Grüße, Günther

MSfree
Beiträge: 6045
Registriert: 25.09.2007 19:59:30

Re: Stable vs Testing

Beitrag von MSfree » 14.04.2019 12:30:49

Trollkirsche hat geschrieben: ↑ zum Beitrag ↑
14.04.2019 00:47:08
Kann ich eigentlich auch nach Upgrade von einem zum anderen System komplett das ganze home dir übernehmen? Bisher habe ich immer, um ein sauberes System zu erhalten, jedes Verzeichnis das ich migrieren wollte, auf das neue System vom Backup übernommen.
Jein. Es geht zwar meistens gut, kann aber in Einzelfällen in die Hose gegen.

Ich hatte mal Probleme mit meinem ~/.kde Verzeichnis. Das nach dem Upgrade neuere KDE wollte mit den alten Einstellungen nichts anfangen und ist abgestürzt. Löschen und neu anlegen lassen hat das Problem zwar behoben, ich mußte dann aber alles, was ich für mich an KDE ändere (Hotkeys, Focus-on-Mouse, Desktoptheme, Farben...), wieder einstellen.

Ich habe in meinem Home aber mehr als nur ein paar Systemdateien. Da sind z.B. auch die Arbeitsverzeichnisse für den Quelltext meiner eigenen Softwareentwicklungen. Sowas kann man natürlich probllemlos übernehmen. Obwohl ich hier auch noch doppelt und dreifach abgesichert bin, weil mein Quellcode auf einem Server mit Subversion (ich war bisher zu faul, auf GIT zu migirieren) verwaltet wird und der Inhalt des SVN-Servers zusätzlich auf ein NAS gesichert ist.

Benutzeravatar
willy4711
Beiträge: 4041
Registriert: 08.09.2018 16:51:16

Re: Stable vs Testing

Beitrag von willy4711 » 14.04.2019 13:53:59

guennid hat geschrieben: ↑ zum Beitrag ↑
14.04.2019 12:21:32
Letzteres schützt alle außer willy vor unliebsamen Überraschungen, aber der weiß auch, was er tut. :wink:
Nö -- auch nicht immer (oder vielleicht : selten) aber wer stolpert und wieder aufsteht, lernt beim nächsten Mal besser aufzupassen :wink:

Ist ja wohl nicht OT, wenn hier auch über das "Verfahren selbst" mal was gesagt wird

Der Thread hat mich natürlich animiert, gleich erst mal in einer VM ein Dist Upgrade auf Buster zu fahren.
Diesmal auf eine andere Art und Weise: Mit Debianaptitude.

Es gibt ja die allgemeine Empfehlung erst mal nach dem Ändern der Sourcen ein

Code: Alles auswählen

apt update && apt upgrade

und anschließend

Code: Alles auswählen

apt full-upgrade
durchzuführen.
Da ich den praktischen Nährwert dieses Verfahrens noch nie so richtig begriffen hatte, wollte ich das diesmal in der Gnome VM
mit Aptitude durchführen.

Also drauflos:

Code: Alles auswählen

aptitude update && aptitude upgrade
Ergebnis: 30 Minuten 50 % Prozessorlast von der VM und ein mir nicht nachvollziehbares Sortieren von Paketen in Hold / Zurückgestellt und ich weis nicht noch was alles.
Hab das dann abgebrochen und mit

Code: Alles auswählen

aptitude full-upgrade
ein zufriedenstellendes Ergebnis gehabt, incl eines wunderschönen Protokolls: NoPaste-Eintrag40694

Frage also:
Ich kann mich dunkel erinnern, igendwann das analog dem oben Geschilderten mit apt gemacht zu haben. Das ging aber ratz batz.

Macht Aptitude da etwas (im Hintergrund) anders wodurch diese Extreme Prozessorbelastung und Dauer zu erklären ist ?

Über eine schlüssige Erklärung warum man unbedingt ein upgrade vor einem full-upgrade machen soll wäre ich auch dankbar.

guennid

Re: Stable vs Testing

Beitrag von guennid » 14.04.2019 14:40:32

Ob man unbedingt ein upgrade vor dem dist-/full-upgrade machen soll, weiß ich gar nicht, aber zumindest beim Release-Wechsel ist es wohl so, dass du dadurch sicherstellst, auf dem letzten Stand des Releases zu sein, von dem du weg willst. Dadurch soll wohl gewährleistet sein, dass der mit dist-/full-upgrade angestoßene Release-Wechsel möglichst problemfrei durchläuft. Ich nehme an, genau das wird geprüft, bevor ein Release freigegeben wird. Upgrade benutze ich nie. Wenn ich einen Release-Wechsel plane, mach' ich mit apt-get vorher eine dist-upgrade für das alte System. Wenn du aber sowieso gehaltene Pakete in der alten Version hast, dann musst du vorher selbst schauen, inwieweit das dist-/full-upgrade auch beim Release-Wechsel damit klarkommt und geeignete Maßnahmen vorher ergreifen. Der Parameter „-s“ gab mir dafür bisher erschöpfend Auskunft. Ob synaptic das in diesem Falle (hold-/Fremd-Pakete) ohne dein Zutun von sich aus schafft, wage ich zu bezweifeln.

Aber nun ja, wenn man so'n Ewigkeits-Testing-Fahrer ist, kriegt man das vielleicht nicht so mit, weiß ich halt nicht. :wink:

Nebenbei: soweit ich weiß, ist es für ein full-/dist-upgrade ziemlich egal, welches cli-Werkzeug du dafür benutzt. Die Stärken aptitudes liegen anderswo - hab' ich mir sagen lassen.

Grüße, Günther

Benutzeravatar
novalix
Beiträge: 1795
Registriert: 05.10.2005 12:32:57
Lizenz eigener Beiträge: MIT Lizenz
Wohnort: elberfeld

Re: Stable vs Testing

Beitrag von novalix » 14.04.2019 16:19:48

Ein einfaches "upgrade" nach Änderung der sources.list auf ein neues Release erneuert auschließlich die Pakete, die bereits installiert sind.
Ein dist- oder full-upgrade spielt auch neu entstandene Abhängigkeiten mit ein und löscht ggf. vorher installierte Abhängigkeiten, die jetzt mit den neuen Paketen in Konflikt stehen.

Deshalb ist es sehr gut möglich, dass die hohe CPU-Last, die @Willy bei dem upgrade beobachtet hat, auf den resolver von aptitude zurückzuführen ist. Bei einem reinen upgrade entsteht eben vorübergehend ein Mischsystem und "eigentlich" ist auch eher davon abzuraten diesen halben Schritt zu gehen.
In der Vergangenheit hat es aber auch schon Release-Wechsel gegeben, bei denen dieses vorsichtige Verfahren in bestimmten Konstellationen angeraten war.
Solche ehemaligen Erfordernisse tradieren sich schon mal durch die Foren, ohne dass es dazu noch eine substantielle Begründung gibt.

Im Zweifel sollte man sich, so es sie denn schon gibt, immer erst mal in den Release-Notes schlau machen, welches Frontend zum Upgrade empfohlen wird.
Das war vor einiger Zeit (iirc sarge-etch, etch-lenny) mal aptitude, weil es zu der Zeit den viel besseren resolver besaß.

Beim letzten Release-Wechsel von jessie auf stretch konnte das aptitude aus jessie (mit dem man das upgrade ja durchführt) aber in bestimmten Konstellationen scheitern, deshalb war die offizielle Empfehlung auch apt, apt-get zu benutzen.*
Ich würde heute davon ausgehen, dass solche dist-upgrades von den Entwicklern hauptsächlich mit apt, apt-get getestet werden, weil das die üblichen Frontends sind und der Vorsprung, den aptitude dereinst beim auflösen von Abhängigkeiten hatte, längst nicht mehr so gewaltig ist.

Allgemein ist zu der Frage "stable oder testing" noch anzumerken: Kommt darauf an.
Für eine stärker server-orientierte Installation ist die Antwort zunächst einmal ganz klar "stable".
Wobei in Zeiten des freeze wie heuer, es durchaus sinnvoll sein kann auch schon zu testing zu greifen. Dann aber logischerweise als Vorgriff auf das kommende stable, also mit dem Codename (z.B. buster) in der sources.list nicht mit "testing".
Auch für Desktop-Clients darf man durchaus die "konservative" Herangehensweise empfehlen, wenn nicht klar ist, dass der User entsprechende Anforderungen an die Aktualität bestimmter Softwarekomponenten hat, oder ein ausgesprochenes Spielkalb ist.

*Eine andere Möglichkeit wäre es gewesen, zunächst nur das Paketmanagement auf den neuen Stand zu bringen, wie es bei einem Release-Wechsel (squeeze-wheezy?) ja auch schon mal erforderlich war.
Das Wem, Wieviel, Wann, Wozu und Wie zu bestimmen ist aber nicht jedermannns Sache und ist nicht leicht.
Darum ist das Richtige selten, lobenswert und schön.

RobertDebiannutzer
Beiträge: 385
Registriert: 16.06.2017 09:52:36

Re: Stable vs Testing

Beitrag von RobertDebiannutzer » 14.04.2019 18:11:39

So gut ist testing doch eigentlich gar nicht für die alltägliche Nutzung:

Testing hat keine Betreuung durch das Sicherheitsteam -> Sicherheitsupdates kommen verzögert:
Please note that security updates for "testing" distribution are not yet managed by the security team. Hence, "testing" does not get security updates in a timely manner. You are encouraged to switch your sources.list entries from testing to stretch for the time being if you need security support. See also the entry in the Security Team's FAQ for the "testing" distribution.
Quelle: https://www.debian.org/releases/testing/
oder:
Compared to stable and unstable, next-stable testing has the worst security update speed. Don't prefer testing if security is a concern.
Quelle: https://wiki.debian.org/DebianTesting
Man kann auch z.B. den Verlauf der Updates von firefox-esr mitverfolgen und sich selber anhand eines Beispiels ein Bild machen: https://tracker.debian.org/pkg/firefox-esr bzw. https://www.debian.org/security/
Am 24.03. z.B. wurde das Update auf "60.6.1esr-1~deb9u1" für stretch bekanntgegeben: https://www.debian.org/security/2019/dsa-4417
Erst am 01.04. wurde die Version in testing auf 60.6.1esr-1 geupdated.

Des Weiteren gibt es - wie @willy4711 erwähnte:
willy4711 hat geschrieben: ↑ zum Beitrag ↑
14.04.2019 07:39:39
gewohnten täglichen "full-upgrade" Modus
- sehr häufig Updates. Das kann man auch als unnötigen Festplatten-Verschleiß sehen, wenn es keine Security-Updates sind?

Zudem kommt es natürlich auf persönliche Präferenz an. Braucht man nicht aus bestimmten Gründen aktuelle Software, ist man vielleicht sogar froh, wenn sich nicht häufig etwas ändert. Ich habe einige Leute im Bekanntenkreis, bei denen bin ich froh, dass die nicht ständig mit neuen Versionen von z.B. libreoffice konfrontiert werden...

Ich möchte noch darauf hinweisen, dass ich persönlich eigentlich schon eher ein Kandidat für testing wäre, aber die Versorgung mit Sicherheitsupdates und die häufigen nicht-Sicherheitsupdates finde ich nicht optimal. Optimal wäre ein halbjähriger Release-Zyklus von stable. Aber das macht Debian aus bestimmten (auch nachvollziehbaren) Gründen eben nicht. Und alternative Distributionen hätten (zumindest für mich) ihre eigenen Nachteile.

slu
Beiträge: 1691
Registriert: 23.02.2005 23:58:47

Re: Stable vs Testing

Beitrag von slu » 15.04.2019 14:10:19

RobertDebiannutzer hat geschrieben: ↑ zum Beitrag ↑
14.04.2019 18:11:39
Man kann auch z.B. den Verlauf der Updates von firefox-esr mitverfolgen und sich selber anhand eines Beispiels ein Bild machen: https://tracker.debian.org/pkg/firefox-esr bzw. https://www.debian.org/security/
Am 24.03. z.B. wurde das Update auf "60.6.1esr-1~deb9u1" für stretch bekanntgegeben: https://www.debian.org/security/2019/dsa-4417
Erst am 01.04. wurde die Version in testing auf 60.6.1esr-1 geupdated.
Es ist so schade das im Freez die Sicherheitsupdates nicht schneller kommen, so kann ich Buster nicht auf die Workstation los lassen. :?
Zuletzt geändert von slu am 15.04.2019 17:24:48, insgesamt 1-mal geändert.
Gruß
slu

Das Server Reinheitsgebot:
Debian Buster, sonst nichts.

Stolzer Gewinner der Jessie Release Wette:
https://wiki.debianforum.de/Jessie_Release_Wette#SIEGER

Antworten