[gelöst] Update auf Testing

[willy4711]

Ich kenne diese Aussage nur für Unstable, also "Siduction".

Dann kennst du falsch
Außerdem ist Unstable nicht Siduction

[Blue]

@niemand:

Sieh’s positiv: du hast nun etwas gelernt.

Yep.

@niemand / willy4711:
Erst einmal "Danke" für Eure konstruktiven Antworten.

Folgende Anschluß-Fragen ergeben sich mir dann:
1) Wenn ich Testing/Bullseye über Synaptic aktualisiere, entspricht das dann einem "full-upgrade"-Befehl im Terminal?
2) Die gleiche Frage gilt bezüglich des Aktualisieren über "Gnome-Software".
3) Wieso brachten erst mehrere "einfachen" upgrades nach dem full-upgrade die Bewältigung besagter Fehlermeldung?

[willy4711]

Der Auszug aus dem log von aptitude (s.O) ist von gestern.

da wird z.B libperl5.30:amd64 5.30.3-4 gepurgt und anschließend libperl5.32:amd64 5.32.0-5 installiert.
Mit einem einfachen upgrade wäre das nicht passiert.

1) Wenn ich Testing/Bullseye über Synaptic aktualisiere, entspricht das dann einem "full-upgrade"-Befehl im Terminal?

Ich mache upgrades grundsätzlich mit aptitude. Schon weil ich nicht 100%ig sicher bin,
was Synaptic mit "intelligent " meint (bezogen auf Testing).
Synaptic benutze ich zur "Recherche" und zum installieren. Dafür ist es ein Super Tool.

2) Die gleiche Frage gilt bezüglich des Aktualisieren über "Gnome-Software".

Ich gehe mal davon aus, dass Gnome das schon richtig machen wird, zumal das ja immer während eines Neustarts passiert.
Aber wissen tue ich es nicht, da ich das "Kaufhaus" so gut wie nie benutze.

3) Wieso brachten erst mehrere "einfachen" upgrades nach dem full-upgrade die Bewältigung besagter Fehlermeldung?

Keinen Ahnung---> der Log mach schlau (meist)

[Blue]

@willy4711: Thx.

Ich verwende seit einiger Zeit auch aptitude.

Interessant ist, dass hier:
https://manpages.debian.org/testing/apt ... .8.de.html nichts davon steht, dass man zum Aktualisieren von Testing nur "full-upgrade" verwenden dürfe.

Ich glaube es Euch aber trotzdem.

[willy4711]

Ich halte mich an das Manual von apt:

upgrade (apt-get(8))
upgrade wird verwendet, um verfügbare Upgrades für alle derzeit auf dem
System installierten Pakete von den in der sources.list(5)
konfigurierten Quellen zu installieren. Neue Pakete werden installiert,
falls dies nötig ist, um Abhängigkeiten zu erfüllen, existierende
werden jedoch nie entfernt. Falls das Upgrade für ein Paket verlangt,
dass ein installiertes Paket entfernt wird, wird dieses Upgrade nicht
durchgeführt.

full-upgrade (apt-get(8))
full-upgrade verrichtet die Funktion von »upgrade«, wird aber auch
installierte Pakete entfernen, falls dies erforderlich ist, um ein
Upgrade des Systems als Ganzes durchzuführen.

Und nun sieh dir mal den Log- Auszug v. Oben nochmals an:posting.php?mode=reply&f=12&t=179289#pr1255353
Mit einem normalen upgrade würden drei Pakete nicht geupgradet werden. Irgendwann geht das dann schief, weil die
Abhängigkeiten nicht mehr erfüllt werden können, oder das Upgrade hält gleich an.

[Blue]

Und noch einmal zu meiner Aussage:

@willy4711:

Abgesehen davon sollte man bei Testing grundsätzlich apt full-upgrade benutzen

Ich kenne diese Aussage nur für Unstable, also "Siduction".

Diese habe ich von hier:
https://debian-handbook.info/browse/de- ... t-get.html

Zitat daraus
Für wichtigere Aktualisierungen, wie den Übergang von einer Debian-Hauptversion zur nächsten, müssen Sie apt full-upgrade benutzen. Mit dieser Anweisung vollzieht apt die Aktualisierung selbst dann, wenn es einige veraltete Pakete entfernen oder neue Abhängigkeiten installieren muss. Dies ist ebenso der Befehl, den Benutzer verwenden, die täglich mit Debians Unstable-Veröffentlichung arbeiten und deren Entwicklung tagtäglich verfolgen. (Edit: die Blaueinfärbung habe ich zur Verdeutlichung vorgenommen) Es ist so einfach, dass es kaum einer Erklärung bedarf: APTs Ansehen begründet sich in dieser großartigen Funktionalität.

@willy4711: Das

Falls das Upgrade für ein Paket verlangt,
dass ein installiertes Paket entfernt wird, wird dieses Upgrade nicht
durchgeführt.

erklärt mir aber die Notwendigkeit von "full-upgrade" für Testing, zumal ich Mitte 2021 Bullseye "Stable" haben will.

[RobertS]

Lang lang ist's her. Mir hats bei einem apt-get update mit anschließendem apt-get dist-upgrade mal die Kiste zerlegt. Damals war die Empfehlung bei einem Versionswechsel zuerst ein apt-get upgrade und anschließend ein apt-get dist-upgrade.
Hintergrund war, glaub ich mich zu erinnern, daß sich irgendwas dem dist-upgrade verweigert hat solange noch eine andere Komponente aktiv war. Ergebnis war dann ein nicht startfähiges System. Meine Angewohnheit seitdem erst ein upgrade, dann ein autoremove und dann ein full-upgrade.
Wobei das lange her ist, beim Rechner der Freundin brauchts erst einen Hardwareschaden bevor ich da größere Dinge ändern darf, da kommt dann gleich ein aktuelles stable, oder auch ein Testing im freeze, drauf. Und meine Kisten laufen eh mit tagesaktuellem Testing/Sid mit Spuren von experimental und stable. Bekommen also eh nur full-upgrade.
Ja auch Teile von stable brauchts ab und an.

[fischig]

Mir hats bei einem apt-get update mit anschließendem apt-get dist-upgrade mal die Kiste zerlegt. Damals war die Empfehlung bei einem Versionswechsel zuerst ein apt-get upgrade und anschließend ein apt-get dist-upgrade.

Ich mach' das als notorischer Stable-Benutzer so, dass ich beim Wechsel des stable-Releases vor dem Wechsel ein letztes dist-upgrade durchführe, dann die sources.list ändere, danach ein dist-upgrade anschaue und erst dann, wenn ich keine Probleme erkenne, auch tatsächlich durchziehe. Das funktioniert hier seit woody. Für entscheidend halte ich die Kontrolle der sources.list. MIt backports habe ich nie Probleme gehabt. Wenn man Fremdrepos aktiv dirinstehen hat, muss man sich vorher Gedanken über mögliche Konsequenzen machen.

„Upgrade“ habe ich wissentlich nie benutzt und weiß auch nicht, wofür das eigentlich nützlich sein soll.
Die hier genannten „Empfehlungen“ (von wem eigentlich?) kommen mir seltsam vor.

[willy4711]

Ich mach' das als notorischer Stable-Benutzer so, dass ich beim Wechsel des stable-Releases vor dem Wechsel ein letztes dist-upgrade durchführe, dann die sources.list ändere, danach ein dist-upgrade anschaue und erst dann, wenn ich keine Probleme erkenne, auch tatsächlich durchziehe. Das funktioniert hier seit woody. Für entscheidend halte ich die Kontrolle der sources.list. MIt backports habe ich nie Probleme gehabt. Wenn man Fremdrepos aktiv dirinstehen hat, muss man sich vorher Gedanken über mögliche Konsequenzen machen.

Genau so und nicht anders sollte man es machen.

[Blue]

@fischic:

„Upgrade“ habe ich wissentlich nie benutzt und weiß auch nicht, wofür das eigentlich nützlich sein soll.

Spannende Aussage eines "notorischen Stable-Benutzers".
Bei Debian-Stable ist Deiner Meinung nach also zum Aktualisieren der Befehl "apt upgrade" nicht nützlich?

[fischig]

Deiner Meinung nach (ist) also zum Aktualisieren der Befehl "apt upgrade" nicht nützlich?

Das habe ich nicht geschrieben. Aber wenn du meinst, er sei nützlich, dann zeig' doch mal, wobei er deiner Meinung nach nützlicher ist als „apt full-upgrade/apt-get dist-upgrade“. Ich bin offen für neue Erkenntnisse. Und wohl gemerkt: Ich rede von stable. Dass der TE von stable nach testing wechseln will macht hier keinen Unterschied.

[Blue]

dann zeig' doch mal, wobei er deiner Meinung nach nützlicher ist als „apt full-upgrade/apt-get dist-upgrade“

Um ein Bild zu verwenden: Ich kann eine Einkaufstüte statt mit einem PKW auch mit einem LKW transportieren.

Und geschrieben hattest Du (sicher ironisierend):

wofür das eigentlich nützlich sein soll (Edit: das "apt upgrade")

Und ich habe Dir geantwortet: zum "Upgraden in Stable" (PKW).
Dass Du dazu auch ein "apt full-upgrade" verwenden kannst (LKW), sei Dir unbenommen.

Was ich Dir aber in diesem Thread "vorwerfe" ist, dass Du falsch lesend behauptet hast, dass jemand bei einem Wechsel von Buster zu Bullseye/Testing "dummfugerweise" zu einem "apt-upgrade" statt korrekterweise "full-upgrade" geraten habe. Das war nicht der Fall. Lies oben nach.

[fischig]

@rockyracoon

Lies oben nach.

Habe ich gemacht.
Zitieren scheint deine starke Seite nicht zu sein. Im Aussagen verdrehen bist du besser.
Ich werde diese Diskussion mit dir nicht weiter fortsetzen. Möge der geneigte Leser sich selbst ein Bild machen.

[mcb]

Mich würde interessieren, warum du folgenden sinnlosen Optionen benutzt (hast ja noch nicht drauf geantwortet):

Code: Alles auswählen

apt -t testing

und

Code: Alles auswählen

--with-new-pkgs upgrade

Das erste verstehe ich überhaupt nicht, wenn man eine ordnungsgemäße sources.list hat.

Zum Letzten habe ich geschrieben, das es bei einen Dist-Upgrade kontraproduktiv ist

Was soll das bewirken ? Sicherlich kein dist-upgrade

[Ja so habe ich das auch gelesen -> man kann wohl auch 2x apt upgrade oder 2x apt full-upgrade mit reboot dazwischen nehmen .... kommt dann auf das gl. raus.

Das ist überhaupt nicht dasselbe. Vielleicht solltest du dich mal mit dem Unterschied
zwischen apt upgrade und apt full-upgrade beschäftigen

1) apt -t testing -> für den Probelauf mit -s Ich war ich zu faul vorher die list zu ändern
2) --with-new-pkgs upgrade <-> ist wirkungslos
3) apt upgrade / dist-upgrade oder full-upgrade ist was anderes ... da lag ich falsch (sorry)

[mcb]

PS:

#964477 - Implicit conflict between libgcc1 and libgcc-s1 prevents upgrade - Debian Bug report logs
https://bugs.debian.org/cgi-bin/bugrepo ... bug=964477

[mcb]

So ich habe es auf einem Desktop durchprobiert -

es gab massig Fehlermeldungen:

aber es geht:

Python2 und 3, gcc-8, mutter und einige andere mußten per Hand upgegraded werden, dann läuft es letztendich durch. (Mein armes Nervenkostüm)

- einen neueren Thunderbird und Firefox bekommt man über sid/unstable sofern gewünscht. Ob die Busterversionen auch gingen habe ich nicht probiert.

Ist ev. dem noch nicht stable / fertig Stand geschuldet.

[Blue]

Auch wenn ihr mich jetzt lyncht, ich hatte es oben genau so beschrieben wie es mcb jetzt auch erlebt hat:
Nach einem korrekten "apt full-update" nach der Änderung der sources.list kamen bei mir Fehlermeldungen, obwohl das nach Ansicht einiger Poster hier nicht sein dürfte.
Danach halfen mir wie bei mcb einige "apt upgrade"-Befehle mit ein oder zwei Re-Boots, um diese Fehler zu beseitigen.
O

Firefox-ESR ist bei Bullseye-Testing eine Versionsstufe niedriger als bei Buster. Wie mcb oben schreibt, kann sich das mit dem Wechsel zu Bullseye-Stable noch ändern.
Viele User verwenden sowieso den aktuellen Firefox im Opt- oder Home-Verzeichnis.

O
O.T.:
Aber ich habe den Ratschlag von willy4711, niemand und fischic angenommen und werde mein intaktes System nun nur noch über "apt full-upgrade" aktualisieren.
Dazu habe ich im Home-Bashrc den Eintrag alias s='su -'
sowie im Root-Bashrc die Einträge
alias u='apt update && apt full-upgrade' für das Update/Upgrade und
alias c='apt autoremove && apt autoclean' zum Bereinigen des Systems vorgenommen.

[OrangeJuice]

Bis jetzt hat das bei meinen Installationen immer einwandfrei von Stable nach Testing geklappt. Selbst ein komplettes zurück zu Stable habe ich mal ausprobiert und hat mit etwas Anpassung geklappt. Ich habe aber auch immer ein apt full-upgrade gemacht.

Ich hole mir den Firefox, Thunderbird und Kernel aus Sid oder experimental. Für den Dektop PC sollte das kein Problem sein. Bis jetzt läuft es damit gut, ich frag mich nur wie es in der Phase läuft, wenn alles eingefroren wird.

Alte Dateien und Konfigs entferne ich mit aptitude.

Code: Alles auswählen

dpkg -l |grep "^rc"
aptitude purge ~c

aptitude search '~o'
aptitude purge '~o'

[Blue]

@OrangeJuice:

Selbst ein komplettes zurück zu Stable habe ich mal ausprobiert und hat mit etwas Anpassung geklappt.

Gratulation.

Alte Dateien und Konfigs entferne ich mit aptitude.

Code: Alles auswählen
dpkg -l |grep "^rc"
aptitude purge ~c
aptitude search '~o'
aptitude purge '~o'

Wobei: cave!
"aptitude search '~o'" findet die gleichen Pakete, welche der Synapic-Paketmanager unter "Installiert (lokal oder veraltet" auflistet.
Darunter befinden sich aber nicht nur obsolete alte Pakete, sonden auch manuell installierte Pakete wie zum Beispiel ein Scanner-Treiber.

[fischig]

Nach einem korrekten "apt full-update" nach der Änderung der sources.list kamen bei mir Fehlermeldungen, obwohl das nach Ansicht einiger Poster hier nicht sein dürfte.
Danach halfen mir wie bei mcb einige "apt upgrade"-Befehle mit ein oder zwei Re-Boots, um diese Fehler zu beseitigen.

Falls mit den „einiger Poster“ ich gemeint sein sollte. Als du dein zielführendes „apt upgrade“-Kommandos einegegeben hast, warst du bereits auf testing, und ich hatte mich wohlweislich aus Aussagen, testing intern betreffend, herausgehalten - nur noch mal zur Erinnerung ans genaue Lesen. Ich kann mir durchaus vorstellen, dass das einfache Upgraden dort seinen Sinn hat, schließlich begibt man sich damit quasi auf ein rolling release mit anderen Bedingungen als sie für stable gelten. Aber dazu weiß ich als „notorischer stable Benutzer“ zu wenig von testing.

Nur so'ne Idee, von der ich selbst nicht recht überzeugt bin: Könnten deine Probleme innerhalb testings damit zusammenhängen, dass du unmittelbar davor, also als du noch auf stable warst, kein full-/distupgrade mit aktueller (stable!) Paketliste durchgeführt hattest.

[willy4711]

aptitude search '~o'

Interessant. Wo hast du denn das "o" aufgegabelt ?
Steht in keinem Manual https://www.debian.org/doc/manuals/apti ... 02.en.html
Doch, aber nur hier:
https://www.debian.org/doc/manuals/apti ... QuickGuide

Habe so was bisher immer mit apt-show-versions gemacht für das oben diskutierte (obsolet):

Code: Alles auswählen

apt-show-versions|grep 'No available version in archive'|awk '{print $1}'

Wider was gelernt

Ps. Aber die "Tüttelchen" kann man weglassen.

[Blue]

@fischic:

...ich hatte mich wohlweislich mit Aussagen, testing intern betreffend, herausgehalten - nur noch mal zur Erinnerung ans genaue Lesen. Ich kann mir durchaus vorstellen, dass das einfache Upgraden dort seinen Sinn hat...

Das war wohl das Mißverständnis, was zu unserem unnötigen Mini-Flame geführt hat.
Mir ging es hier im Thread einfach nur darum, anderen Umsteigern meine Erfahrung zugänglich zu machen. Mein Bullseye-Testing läuft btw wie eine Eins.
Shake Hands.

...Ich behaupte nach wie vor: Innerhalb stables ist ein einfaches upgrade überflüssig/sinnlos. Falls ich irre, zeig's mir...

Um offen zu sein, kann ich dazu nichts Belastbares sagen.
Ich habe bisher für Stable gelesen, dass ein "apt upgrade" zum Aktualisieren vorzunehmen sei.
Wie oben geschrieben, vertraue ich aber auf das Wissen von Dir, willy4711 und niemand und habe in meinem Aktualisierungs-Alias das "full-upgrade" aufgenommen.
Schaden kann das sowieso nicht.

[fischig]

Innerhalb stables konnte ich bisher keinen Sinn für's einfache upgrade erkennen. Deswegen ganz ehrlich: Wenn mir jemand zeigte, unter welchen Bedingungen es einem full-/dist-upgrade vorzuziehen wäre, der/die hätte meinen Kenntnisstand erweitert.

[KP97]

Nur ganz grob aus'm Koppe:
Ein einfaches apt upgrade aktualisiert nur die bereits vorhandenen Pakete. Sollten aber neue, zusätzliche Pakete notwendig werden, ist das in einem Stable nicht machbar, da ja,
wie man weiß, keine neuen Pakete bzw. Versionen einfließen.
Ganz anders bei einem Testing bzw. Sid. Da kommen immer wieder neue, zusätzliche Pakete mit neuen Versionen, da ist ein apt full-upgrade zwingend notwendig.
Würde man hier nur ein apt upgrade ausführen, würden benötigte neue Pakete nicht mit installiert und das System über kurz oder lang unbrauchbar.

Der Einfachheit halber sollte man sich merken, immer ein apt full-upgrade auszuführen.
Bei einem Stable schadet es nicht und bei Testing bzw. Unstable ist es Pflicht.

[OrangeJuice]

aptitude search '~o'

Interessant. Wo hast du denn das "o" aufgegabelt ?

Da weiß ich nicht mehr, irgendwo in den Weiten des Netzes gefunden und dann für mich als brauchbar übernommen, da ich eh alles per Terminal erledige. Man muss nur aufpassen, weil damit auch eigene Pakete wie Drucker oder selbst kompilierter/installierte Kernel gefunden werden. Man kann dann aber auch einfach die zu entfernenden Pakete mit eine apt purge entfernen und die man nicht weg haben will so belassen. Das muss dann jeder selbst entscheiden, was er entfernen will.

Mit --help findet man zumindest etwas.

Code: Alles auswählen

aptitude --help
Options:
-o key=val      Directly set the configuration option named 'key'.