'apt' - Fragen, Erkennen und Verstehen ??

[tscott]

Guten Morgen,

allen noch ein gesundes neues Jahr.

Aus gegebenen Anlaß - nicht so gut gelaufenes 'apt full-upgrade' (siehe hier: 'viewtopic.php?t=183064') - habe ich zum Umgang mit dem Tool 'apt' ein paar Grundsätzliche Verständnisfragen:

(a) Info zum Löschen von Paketen bei 'apt full-upgrade'
-'apt upgrade' installiert ja alle neuen und aktualisierbaren Pakete auf dem Rechner.
- 'apt full-upgrade' tut dies auch nur dass zusätzlcih noch alle nicht mehr benötigten Pakete gelöscht werden
Frage: Woher 'weiß' apt welche Pakete nicht mehr gebraucht werden? - Hintergrund: bei meinem 'apt full-update' Aufruf sollte auch 'roundcube' mitsamt Datenbank gelöscht werden. Wie lautet der 'apt' Aufruf: "zeige alle nicht benötigten Pakete"?

(b) Anzeige aller bereits installierten 'non-free' und/oder 'contrib' Pakete
Frage: Wie kann ich mir alle meine auf meinem System installierten Pakete anzeigen lassen die aus den Repositories 'contrib' und/oder 'non-free' stammen?

(c) Was wird bei m Aufruf 'apt upgrade -no-newpackages' genau getan (und/oder nicht getan) ?
Frage: Bei dem o.g. Aufruf 'apt upgrade -no-newpackages' wird ein Upgrade durchgeführt. Ich hatte anhand einer Upgrade Anleitung von Buster auf Bullseye diesen Befehl ausgeführt. Es wurde daraufhin auch "etwas" gemacht. Aber was genau?

(d) Rückwärtssynchronisation der installierten Pakete ?
'apt' scheint sich ja alle bereits im System installierten Pakete irgendwo zu merken. Also alle manuell installierten und auch alle automatisch installierten Pakete. Alle diese Pakete aufzulisten ist einfach. Sollte man aber darüber hinaus ein Paket- z.B. per 'dpkg -i' - nicht per 'apt' installiert haben, dann würde dieses Paket wahrscheinlich nicht in der Liste der bereits installierten Pakete auftauchen.
Frage: Wie kann man nicht per 'apt' installierte Pakete nachträglich der Liste der per 'apt' installierten Pakete hinzufügen? (siehe auch (a) wenn 'apt' ungewollt Pakete bei einem 'apt full-upgrade' löscht')

Hintergrund: Mein Server ist nun in so einer Art Schwebezustand zwischen Buster und Bullseye. 'apt upgrade -no-new-packages' wurde gemacht. Aber ein 'apt full-upgrade' hatte ja leider nicht geklappt. Ich bin ehrlich etwas ratlos was ich nun machen soll und hin und her gerissen: Der Server läuft zwar, aber es waren 539 Module auf das Upgrade.

Ciao
Tom

[Meillo]

@all: Das sollten doch nicht so schwierige Fragen sein, dass hier nach einem dreiviertel Tag noch gar keine Antworten da sind. Vielleicht ist der Thread nur untergegangen. Darum hole ich in mal hervor ...



Zu (c) kann ich eine Loesung beitragen, die zwar nicht (direkt) ueber apt laeuft, aber die Antwort auch erzeugt: Das Paket vrms listet genau diese Pakete auf.

[fischig]

Die Annahmen unter a) stimmen bereits nicht. apt upgrade kannst du als im Normalgebrauch überflüssiges Kommando schnell vergessen. Sinn abgewinnen können dem vielleicht Spezialisten. Ich bin keiner.
apt full-upgrade überschreibt dir sämtliche mit apt installierten Pakete einschließlich vielleicht noch nicht vorhandener jetzt aber dafür benötigter libs, wenn neuere pakete im Repo vorhanden sind.
Eine auf unzutreffenden Annahmen basierende Frage lässt sich schlecht beantworten.

zu d:
apt kennt auch per dpkg -i installierte Pakete. dpkg ist der Paketmanager, apt ist nur der benutzerfreundlichere Aufsatz.

[reox]

apt upgrade kannst du als im Normalgebrauch überflüssiges Kommando schnell vergessen

Das Debian Handbuch sagt das was anderes https://www.debian.org/releases/stable/ ... al-upgrade
Ich seh den Sinn schon darin, dass ein upgrade jedenfalls nichts deinstalliert und man somit leichter überprüfen kann ob man da weitermachen will.
Ich finde den zweistufigen upgrade Prozess für oldstable->stable durchaus sinnvoll. Für eine testing/sid maschine aber meistens unbrauchbar.

[fischig]

Was deinstalliert ein full/dist-upgrade? Habe ich noch nie beobachtet.

Kann es sein, dass es im Handbuch um den Release-Wechsel geht? Selbst da benutze ich kein einfaches upgrade: Zunächst wird das alte release per full-ugrade auf Vordermann gebracht (keinerlei Deinstallation), anschließend wird die sources.list aufs neue release gestellt und nach update ein neues full-upgrade angestoßen. und bevor das ernst wird, siehst du sehr genau, was da evtl(!) alles rausfliegt und kannst vorher reagieren. ein einfaches upgrade ist so oder so überflüssig. Wie gesagt, ich kann mir vorstellen, dass es spezielle Szenarien gibt, in denen es sinnvoll sein mag. Ich kenne aber keine.

Von testing und sid lasse ich sowieso die Finger.

[reox]

Was deinstalliert ein full/dist-upgrade? Habe ich noch nie beobachtet.

Man muss nur mal in der manpage schauen

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.

IMO reicht bei upgrades (zB security) von alles unter und incl stable ein upgrade immer aus - nachdem sich dort die Abhänigkeiten nie (?) ändern werden.
Allerdings kann es ja bei einem upgrade von einem release dazu kommen, dass Paket A mit Paket B bricht und daher Paket B deinstalliert werden muss. zB wenn /bin/abc jetzt von Paket A kommt und nicht von B und es nicht über alternatives installiert werden soll.

Ich kenne den Fall vom OP jedenfalls auch: Warum auch immer, soll bei einem full-upgrade ein Paket entfernt werden, welches man noch braucht. Meist ist es dann als automatisch installiert markiert und durch $gründe ist das Paket über das man es installiert hat (und welches dann das andere Paket halten würde) irgendwie rausgeflogen...

[willy4711]

Zur Veranschaulichung mal ein Log von aptitude full-upgrade (gleichbedeutend mit apt full-upgrade)
Hier kann man sehr schön sehen, was bei einem full-upgrade passiert, und was bei einem normalen upgrade nicht
nicht durchgeführt werden würde (alle REMOVES).

Code: Alles auswählen

Aptitude 0.8.13: log report
Fri, Dec  3 2021 14:29:27 +0100

  IMPORTANT: this log only lists intended actions; actions which fail
  due to dpkg problems may not be completed.

Will install 49 packages, and remove 18 packages.
438 MB of disk space will be used
========================================
[REMOVE, NOT USED] libcodec2-0.9:amd64 0.9.2-4
[REMOVE, NOT USED] libopencv-calib3d4.5:amd64 4.5.3+dfsg-1+b2
[REMOVE, NOT USED] libopencv-contrib4.5:amd64 4.5.3+dfsg-1+b2
[REMOVE, NOT USED] libopencv-core4.5:amd64 4.5.3+dfsg-1+b2
[REMOVE, NOT USED] libopencv-dnn4.5:amd64 4.5.3+dfsg-1+b2
[REMOVE, NOT USED] libopencv-features2d4.5:amd64 4.5.3+dfsg-1+b2
[REMOVE, NOT USED] libopencv-flann4.5:amd64 4.5.3+dfsg-1+b2
[REMOVE, NOT USED] libopencv-highgui4.5:amd64 4.5.3+dfsg-1+b2
[REMOVE, NOT USED] libopencv-imgcodecs4.5:amd64 4.5.3+dfsg-1+b2
[REMOVE, NOT USED] libopencv-imgproc4.5:amd64 4.5.3+dfsg-1+b2
[REMOVE, NOT USED] libopencv-ml4.5:amd64 4.5.3+dfsg-1+b2
[REMOVE, NOT USED] libopencv-objdetect4.5:amd64 4.5.3+dfsg-1+b2
[REMOVE, NOT USED] libopencv-photo4.5:amd64 4.5.3+dfsg-1+b2
[REMOVE, NOT USED] libopencv-shape4.5:amd64 4.5.3+dfsg-1+b2
[REMOVE, NOT USED] libopencv-stitching4.5:amd64 4.5.3+dfsg-1+b2
[REMOVE, NOT USED] libopencv-video4.5:amd64 4.5.3+dfsg-1+b2
[REMOVE, NOT USED] libopencv-videoio4.5:amd64 4.5.3+dfsg-1+b2
[REMOVE, NOT USED] libopencv-viz4.5:amd64 4.5.3+dfsg-1+b2
[INSTALL, DEPENDENCIES] libcodec2-1.0:amd64 1.0.1-3
[INSTALL, DEPENDENCIES] libopencv-calib3d4.5d:amd64 4.5.4+dfsg-9
[INSTALL, DEPENDENCIES] libopencv-contrib4.5d:amd64 4.5.4+dfsg-9
[INSTALL, DEPENDENCIES] libopencv-core4.5d:amd64 4.5.4+dfsg-9
[INSTALL, DEPENDENCIES] libopencv-dnn4.5d:amd64 4.5.4+dfsg-9
[INSTALL, DEPENDENCIES] libopencv-features2d4.5d:amd64 4.5.4+dfsg-9
[INSTALL, DEPENDENCIES] libopencv-flann4.5d:amd64 4.5.4+dfsg-9
[INSTALL, DEPENDENCIES] libopencv-highgui4.5d:amd64 4.5.4+dfsg-9
[INSTALL, DEPENDENCIES] libopencv-imgcodecs4.5d:amd64 4.5.4+dfsg-9
[INSTALL, DEPENDENCIES] libopencv-imgproc4.5d:amd64 4.5.4+dfsg-9
[INSTALL, DEPENDENCIES] libopencv-ml4.5d:amd64 4.5.4+dfsg-9
[INSTALL, DEPENDENCIES] libopencv-objdetect4.5d:amd64 4.5.4+dfsg-9
[INSTALL, DEPENDENCIES] libopencv-photo4.5d:amd64 4.5.4+dfsg-9
[INSTALL, DEPENDENCIES] libopencv-shape4.5d:amd64 4.5.4+dfsg-9
[INSTALL, DEPENDENCIES] libopencv-stitching4.5d:amd64 4.5.4+dfsg-9
[INSTALL, DEPENDENCIES] libopencv-video4.5d:amd64 4.5.4+dfsg-9
[INSTALL, DEPENDENCIES] libopencv-videoio4.5d:amd64 4.5.4+dfsg-9
[INSTALL, DEPENDENCIES] libopencv-viz4.5d:amd64 4.5.4+dfsg-9
[INSTALL, DEPENDENCIES] linux-headers-5.15.0-2-amd64:amd64 5.15.5-1
[INSTALL, DEPENDENCIES] linux-headers-5.15.0-2-common:amd64 5.15.5-1
[INSTALL, DEPENDENCIES] linux-image-5.15.0-2-amd64:amd64 5.15.5-1
[UPGRADE] ffmpeg:amd64 10:4.4.1-dmo2 -> 10:4.4.1-dmo4
[UPGRADE] gir1.2-gtk-3.0:amd64 3.24.30-3 -> 3.24.30-4
[UPGRADE] gtk-update-icon-cache:amd64 3.24.30-3 -> 3.24.30-4
[UPGRADE] libavcodec-dev:amd64 10:4.4.1-dmo2 -> 10:4.4.1-dmo4
[UPGRADE] libavcodec58:amd64 10:4.4.1-dmo2 -> 10:4.4.1-dmo4
[UPGRADE] libavdevice58:amd64 10:4.4.1-dmo2 -> 10:4.4.1-dmo4
[UPGRADE] libavfilter7:amd64 10:4.4.1-dmo2 -> 10:4.4.1-dmo4
[UPGRADE] libavformat-dev:amd64 10:4.4.1-dmo2 -> 10:4.4.1-dmo4
[UPGRADE] libavformat58:amd64 10:4.4.1-dmo2 -> 10:4.4.1-dmo4
[UPGRADE] libavutil-dev:amd64 10:4.4.1-dmo2 -> 10:4.4.1-dmo4
[UPGRADE] libavutil56:amd64 10:4.4.1-dmo2 -> 10:4.4.1-dmo4
[UPGRADE] libgail-3-0:amd64 3.24.30-3 -> 3.24.30-4
[UPGRADE] libgtk-3-0:amd64 3.24.30-3 -> 3.24.30-4
[UPGRADE] libgtk-3-bin:amd64 3.24.30-3 -> 3.24.30-4
[UPGRADE] libgtk-3-common:amd64 3.24.30-3 -> 3.24.30-4
[UPGRADE] libgtk-3-dev:amd64 3.24.30-3 -> 3.24.30-4
[UPGRADE] libjxr-tools:amd64 1.1-6+b1 -> 1.2~git20170615.f752187-3
[UPGRADE] libjxr0:amd64 1.1-6+b1 -> 1.2~git20170615.f752187-3
[UPGRADE] libpostproc55:amd64 10:4.4.1-dmo2 -> 10:4.4.1-dmo4
[UPGRADE] libswresample-dev:amd64 10:4.4.1-dmo2 -> 10:4.4.1-dmo4
[UPGRADE] libswresample3:amd64 10:4.4.1-dmo2 -> 10:4.4.1-dmo4
[UPGRADE] libswscale5:amd64 10:4.4.1-dmo2 -> 10:4.4.1-dmo4
[UPGRADE] linux-compiler-gcc-11-x86:amd64 5.15.3-1 -> 5.15.5-1
[UPGRADE] linux-headers-amd64:amd64 5.15.3-1 -> 5.15.5-1
[UPGRADE] linux-image-amd64:amd64 5.15.3-1 -> 5.15.5-1
[UPGRADE] linux-kbuild-5.15:amd64 5.15.3-1 -> 5.15.5-1
[UPGRADE] linux-libc-dev:amd64 5.15.3-1 -> 5.15.5-1
[UPGRADE] python3-opencv:amd64 4.5.3+dfsg-1+b2 -> 4.5.4+dfsg-9

[Meillo]

Zur Veranschaulichung mal ein Log von aptitude full-upgrade (gleichbedeutend mit apt full-upgrade)
Hier kann man sehr schön sehen, was bei einem full-upgrade passiert, und was bei einem normalen upgrade nicht
nicht durchgeführt werden würde (alle REMOVES).

Mit den Removes hast du zwar recht, aber ich finde, dass das nicht das beste Beispiel ist, da Removes wegen Nichtnutzung eigentlich egal sind. Der interessante Fall sind Removes wegen Konflikten. Dort unterscheiden sind upgrade und full-upgrade in relevanter Weise. Mit upgrade kann man keine Upgradepfade finden, d.h. Konflikte loesen, die das Entfernen eines (dann obsoleten) Paketes beinhalten. Solange man nur Paketversionen erhoehen und ggf. neue Abhaengigkeiten reinziehen will, ist upgrade passend. Bei komplexeren Szenarien bleiben upgrade aber manche Moeglichkeiten verschlossen, die man mit full-upgrade hat. -- So jedenfalls habe ich das verstanden.

[willy4711]

Wenn du dir die [REMOVE, NOT USED] in dem Beispiel LOG anschaust, werden die alle im Nachhinein durch
[INSTALL, DEPENDENCIES] wieder ersetzt.
Ich bin mir ziemlich sicher, das diese Pakete sonst nicht geupdatet würden.

Was genau ein [REMOVE, NOT USED] statt eines normalen [UPGRADE] auslöst kann ich im Einzelnen nur vermuten:

Geänderte Abhängigkeiten / andere Pfade / Manpages usw. wären eventuell solche Trigger.

EDIT:

Das [REMOVE, NOT USED] ist bei Aptitude die Standard - Angabe. ein "nacktes" [REMOVE] hab ich noch nicht gesehen.

[fischig]

@willy
Bezüglich meiner These: „einfaches upgrade ist im allgemeine überflüssig“ wäre interessant gewesen, was mit dem full-upgrade erreicht werden soll: Aktualisierung eines bereits installierten Releases oder Sprung auf ein neues Release. Ich tippe bei deinem Beispiel mal auf letzteres. Und ich wüsste nicht, warum man die Entfernung nicht mehr benutzter libs nicht durchwinken sollte. Bei der Aktualisierung eines installierten releases hätte das full-upgrade genauso wenig wie ein einfaches upgrade, nämlich nichts entfernt.
Ein einfaches upgrade kann man eh nur auf ein installiertes release loslassen. beim Release-Wechsel muss man ein full-upgrade fahren. Wenn man das einfache upgrade nicht für (im Allgemeinen, wohlgemerkt!) überflüssig hält, muss man (am installierten Release) zeigen, wo es mehr kann/besser ist als ein full-upgrade.

[willy4711]

Bezüglich meiner These: „einfaches upgrade ist im allgemeine überflüssig“ wäre interessant gewesen, was mit dem full-upgrade erreicht werden soll: Aktualisierung eines bereits installierten Releases oder Sprung auf ein neues Release. Ich tippe bei deinem Beispiel mal auf letzteres.

Nee - das ist ein stinknormales tägliches Upgrade (Testing), wie ich es jeden Tag fahre.
Beim Release -Wechsel hab ich nach ein paar Tagen Wartezeit auch nichts anderes gemacht Ist bei Testing eh nicht so
dramatisch.

Natürlich ist das [REMOVE, NOT USED] häufig überhaupt nicht vorhanden und es gibt nur [UPGRADE].

Aber dass das normale Upgrade an sich überflüssig ist, sehe ich wie du. Jedenfalls fällt mit kein Szenario ein, wo man damit im
Vorteil wäre.

[reox]

stinknormales tägliches Upgrade (Testing),

wie ich sagte: ein `upgrade` allein ist auf testing unbrauchbar

beim Release-Wechsel muss man ein full-upgrade fahren

ja, steht ja auch so im Handbuch. Dennoch ist ein zweistufiges upgrade sinnvoll denn ...

Und ich wüsste nicht, warum man die Entfernung nicht mehr benutzter libs nicht durchwinken sollte

... das ist nämlich nicht immer das einzige was entfernt wird.
Wie gesagt, es kann passieren, dass full-upgrade ein Paket entfernen will, welches ich eigentlich behalten will - siehe das roundcube problem vom OP. Man muss sich das im Einzelfall anschauen warum das passiert, meistens liegt der Grund schon viele viele apt aufrufe zurück.
Ich bin mir nicht sicher wie man so einen Fall konstruieren kann, es ist mir aber auch schon selber passiert.

Ich mache auf meinen stable kisten immer nur ein upgrade, weil so selbst bei nur halbherzigen draufschauen sichergestellt ist, dass ich sicher nie etwas entferne. Ich find die beiden Befehle durchaus sinnvoll, aber ymmv

[Meillo]

Ich stimme dir zu, reox.

Ich mache auf meinen stable kisten immer nur ein upgrade, weil so selbst bei nur halbherzigen draufschauen sichergestellt ist, dass ich sicher nie etwas entferne. Ich find die beiden Befehle durchaus sinnvoll, aber ymmv

Wie ich geschrieben habe: Wenn man nur die Versionen von bestehenden Paketen hochziehen und ggf. neue Abhaengigkeiten installieren will, dann ist upgrade die beste Option, weil sie sicher stellt, dass nichts kaputt geht und man nichts aus Versehen (wegen Konflikten) entfernt. Fuer ein Stable-System (im Sinne von Produktionsumgebung, die sich nicht veraendern soll, ausser dass man Security-Fixes haben will) ist das IMO die beste weil sicherste Option. Also immer dann wenn man moeglichst wenig aendern will. Dann braucht man die zusaetzlichen Upgradepfade von full-upgrade auch nicht.

Auf einem Testing oder sonst einem System auf dem sich viel aendert, sieht die Situation anders aus. Da ist ein ganz anderes Szenario als eine sehr stabile (im Sinne von sich wenig veraendernde) Kiste.

Wie auch immer. Ich habe mir in jedem Fall genau angeschaut was installiert und ggf. entfernt werden soll bevor ich es gemacht habe. Dann kann man naemlich auch einfach beide Optionen ausprobieren und die Unterschiede vergleichen ... *bevor* man sie durchfuehrt.

[tscott]

Guten Morgen,

und ein Hallo in die Runde vom Threadersteller. Genauso ungefähr habe ich mir das vorgestellt: Eine lebhafte Diskussion was apt eigentlich genau macht, denn ich weiß es nicht und scheinabar ist das alles doch nicht ganz so klar wie Kloßbrühe wie einige meinen.

Ich habe es am Dienstag vor einer Woche selbst erlebt wie ätzend das ist, wenn nach einem 'apt full-upgrade' erst einmal gar nichts mehr geht und - wie bei mir - plötzlich kein Netzwerkinterface auffindbar ist weil das Kernel Modul mit der Hardware nicht zusammen läuft. Und dabei habe ich ja anscheinend noch Glück gehabt, denn schlimmer wären wohl Grafikprobleme denn dann kann man nichtmal was sehen. Deshalb möchte ich gerne mal Klarheit für mich bringen was da alles passiert wenn 539 Module aktualisiert werden und 20 gelöscht werden.... ....und vieleicht kommt ja in der Diskussion ja auch was für andere rum. Gut dass es rsync backups gibt um den vorherigen Zustand wieder herstellen zu können. Aber das kann ja eigentlich nicht Sinn der Sache sein.

Auf jeden Fall schon mal vielen Dank für Eure Einlassungen und ich lese sie mir alle genau durch. Motto: Fragen, Erkennen und Verstehen. Mein alter Prof. hatte da immer einen Spruch parat: "Es gibt einen Unterschied zwischen 'verstehen' und 'begreifen'".

Wie es scheint läuft es momentan auf dieses Vorgehen hinaus wenn man ein Releasewechsel durchführen möchte:
(1) sources.list editieren (contrib non-free nicht vergessen)
(2) 'apt update'
(3) 'apt upgrade -no-new-pkgs'
(3a) rsync Backup der ganzen Platte (außer System generierte Verzeichnisse und temp)
(3b) Reboot und gucken ob geht
(4) 'apt upgrade'
(4a) noch ein rsync Backup der ganzen Platte (außer System generierte Verzeichnisse und temp)
(4b) Reboot und gucken ob geht
(5) 'apt full-upgrade'
(5a) noch ein rsync Backup der ganzen Platte (außer System generierte Verzeichnisse und temp)
(5b) Reboot und gucken ob geht

Eine Frage:

Ich mache auf meinen stable kisten immer nur ein upgrade, weil so selbst bei nur halbherzigen draufschauen sichergestellt ist, dass ich sicher nie etwas entferne. Ich find die beiden Befehle durchaus sinnvoll, aber ymmv

Aber dann kannst Du niemals ein Release-Wechsel durchfürhen, richtig? Dann bekommst du spätestens nach 5 Jahren keine Updates mehr.

und noch eine Frage:

Wie gesagt, es kann passieren, dass full-upgrade ein Paket entfernen will, welches ich eigentlich behalten will - siehe das roundcube problem vom OP. Man muss sich das im Einzelfall anschauen warum das passiert...

Wie kann ich mir das anschauen? Wie lautet der 'apt'-Aufruf für: "Hallo 'apt' sag mir doch mal warum du paket-x deinstallieren willst?". Finde ich schwierig. In dem Fall von Roundcube ist das Paket ja auch nicht automatisch erstellt. Ich habe das ja auch nur bemerkt weil bei der Deinstallation auch ein Deinstallationsdialog aufpoppt in dem man gefragt wird ob man die mysql Datenbank behalten möchte oder nicht, weil man die ja dann auch nicht mehr braucht

Bis dann
Tom

[tobo]

Ich habe es am Dienstag vor einer Woche selbst erlebt wie ätzend das ist, wenn nach einem 'apt full-upgrade' erst einmal gar nichts mehr geht [...]

Das hat überhaupt nichts mit dem hier angedeuteten Unterschied (Upgrade vs Dist/Full-Upgrade) zu tun: Du redest von einem Release-Wechsel - da kann man überhaupt keine allgemeinen Aussagen treffen! Es gibt für jeden Wechsel eine eigene vorgeschlage Upgrade-Lösung, welche jeweils nochmal an die eigene Umgebung angepasst werden muss. Sollte bei dir also der vorgeschlagene Weg des Upgrades scheitern, dann wurde dein System vermutlich vorher nicht richtig auf das Upgrade vorbereitet!

Wenn man nur die Versionen von bestehenden Paketen hochziehen und ggf. neue Abhaengigkeiten installieren will, dann ist upgrade die beste Option, weil sie sicher stellt, dass nichts kaputt geht und man nichts aus Versehen (wegen Konflikten) entfernt.

Was ist das denn für eine Logik? Wenn da ein Installationskonflikt besteht, dann ist das kein Versehen, sondern ein Problem. Es gibt irgendeinen Widerspruch, der dann aber ganz bestimmt aufgelöst werden sollte. Wen das alles nicht interessiert, der sollte dann folgerichtig auch kein Paketsystem benutzen.

[reox]

Aber dann kannst Du niemals ein Release-Wechsel durchfürhen, richtig? Dann bekommst du spätestens nach 5 Jahren keine Updates mehr.

Das hab ich ja nie gesagt Solange ich innerhalb eines Releases (<= stable) bin nehme ich upgrade, bei testing/sid full-upgrade und bei einem Release upgrade halte ich mich an das Handbuch und mache den Zweistufigen Ansatz (oder wenns schnell gehen soll oder egal ist - zB Entwicklungs VM) dann auch mal gleich full-upgrade.

Wie es scheint läuft es momentan auf dieses Vorgehen hinaus wenn man ein Releasewechsel durchführen möchte:

Naja oder du hälst dich an das Handbuch - ich find dort ist es eh alles sehr gut beschrieben.
Jedenfalls solltest du das Backup machen bevor du überhaupt irgendwas angreifst. Snapshots sind da auch ganz praktisch.

Ich habe das ja auch nur bemerkt weil bei der Deinstallation auch ein Deinstallationsdialog aufpoppt

Daher muss man immer erst die Liste durchgehen, an Paketen die da gelöscht werden sollen! Es macht auch Sinn ein solches upgrade erstmal mit --simulate zu starten, damit man nicht irgendwo im Affekt y<CR> drück (als ob mir das noch nie passiert wäre ).

Hallo 'apt' sag mir doch mal warum du paket-x deinstallieren willst

äh da bin ich akut auch überfragt. Ich bild mir eine es hätte ein Option von apt gegeben um das auszugeben aus welchem grund ein Paket entfernt/installiert/geupdated werden sollte.
Ansonsten ist apt show $paket, apt policy $paket, und apt-mark ganz hilfreich. Aber es sollte auch irgendwas geben um auszugeben wo der konflikt herkommt

[willy4711]

Nun mag ja jeder "kochen"wie er will.
nicht sinnvoll finde ich es aber, solch seltsame Befehle wie

Code: Alles auswählen

apt upgrade -no-new-pkgs

hier als sinnvolles Vorgehen hinzustellen, und sich im Anschluss zu beschweren, dass apt
"Mist" baut.
Ich habe noch in keinem Tutorial derartiges gesehen, weiß auch nicht, was es Sinnvolles bewirken soll.
Ich habe beim letzten Release-Wechsel 11 Vm`s ein Full Upgrade verpasst, ohne das bei einer einzigen was schief gelaufen wäre.
(habe kein Produktivsystem mit Stable)
Das Vorgehen ist immer das gleiche, und das seit Jahren:

Mit der alten sources.list, wobei aptitude bzw. apt wahlfrei ist.

Code: Alles auswählen

aptitude update && aptitude full-upgrade

Code: Alles auswählen

aptitude purge ~c

Code: Alles auswählen

apt autopurge

Code: Alles auswählen

apt clean

Neustart -- > Sources.list ändern

Code: Alles auswählen

aptitude update && aptitude full-upgrade

Das sollte es sein. Wenn da was schief läuft liegt es doch meist an irgendwelchen "individuellen" Einstellungen, Fremdpaketen
usw. die vorher einfach vergessen wurden.

Den Grund suchen, warum ein Paket installiert ist kann man problemlos mit

Code: Alles auswählen

aptitude why [Paketname]

[tobo]

Das Vorgehen ist immer das gleiche, und das seit Jahren:

Das ist falsch! Ich kann mich an mindestens 2 Fälle erinnern, die davon abweichen. Einmal sollte zuerst ein upgrade und dann ein dist-upgrade gemacht werden und einmal sollte zuvor nur apt* angehoben werden und dann erst die eigentliche Upgrade-Prozedur.

[Meillo]

Wenn man nur die Versionen von bestehenden Paketen hochziehen und ggf. neue Abhaengigkeiten installieren will, dann ist upgrade die beste Option, weil sie sicher stellt, dass nichts kaputt geht und man nichts aus Versehen (wegen Konflikten) entfernt.

Was ist das denn für eine Logik? Wenn da ein Installationskonflikt besteht, dann ist das kein Versehen, sondern ein Problem. Es gibt irgendeinen Widerspruch, der dann aber ganz bestimmt aufgelöst werden sollte.

Habe ich etwas anderes gesagt?

[tscott]

Daher muss man immer erst die Liste durchgehen, an Paketen die da gelöscht werden sollen! Es macht auch Sinn ein solches upgrade erstmal mit --simulate zu starten, damit man nicht irgendwo im Affekt y<CR> drück (als ob mir das noch nie passiert wäre ).

'--simulate' ist eine gute Idee.

Nun mag ja jeder "kochen"wie er will.
nicht sinnvoll finde ich es aber, solch seltsame Befehle wie

Code: Alles auswählen

apt upgrade --without-new-pkgs

hier als sinnvolles Vorgehen hinzustellen, und sich im Anschluss zu beschweren, dass apt
"Mist" baut.
Ich habe noch in keinem Tutorial derartiges gesehen, weiß auch nicht, was es Sinnvolles bewirken soll.

Doch, aber ich, hier: https://www.debian.org/releases/bullsey ... tes.en.pdf (Kapitel 4.4.4). Das ist die Original Anleitung für ein Releasewechsel.

Den Grund suchen, warum ein Paket installiert ist kann man problemlos mit

Code: Alles auswählen

aptitude why [Paketname]

Top Tipp

Aber so langsam kommt Bewegung in die Unterhaltung. Das finde ich sehr gut.

Ciao
Tom

[tobo]

Wenn man nur die Versionen von bestehenden Paketen hochziehen und ggf. neue Abhaengigkeiten installieren will, dann ist upgrade die beste Option, weil sie sicher stellt, dass nichts kaputt geht und man nichts aus Versehen (wegen Konflikten) entfernt.

Was ist das denn für eine Logik? Wenn da ein Installationskonflikt besteht, dann ist das kein Versehen, sondern ein Problem. Es gibt irgendeinen Widerspruch, der dann aber ganz bestimmt aufgelöst werden sollte.

Habe ich etwas anderes gesagt?

Auf ein dist-upgrade zu verzichten, damit man nichts wegen Konflikten entfernen muss, ist ungefähr dieselbe Vorgehensweise, wie als Ziege den Kopf in den Sand zu stecken, weil unweit ein Löwe rumläuft. Besser man gibt der Ziege ein Laserschwert...

[Meillo]

Auf ein dist-upgrade zu verzichten, damit man nichts wegen Konflikten entfernen muss, ist ungefähr dieselbe Vorgehensweise, wie als Ziege den Kopf in den Sand zu stecken, weil unweit ein Löwe rumläuft. Besser man gibt der Ziege ein Laserschwert...

Ziege mit einem Laserschwert?


Einen Konflikt sehe ich beim upgrade doch auch, bloss dass es damit unmoeglich ist, eine Loesung dafuer zu finden. Ich laufe also zwangslaeufig gegen eine Barriere und werde dadurch gezwungen mich mit dem Problem zu befassen. (Das ist etwas anderes als den Kopf in den Sand zu stecken.)

Bei einem full-upgrade muss ich jedes Mal sehr aufmerksam die Aenderungsliste durchgehen, damit ich einen Konfliktfall nicht uebersehe. Dort gibt es nicht diese Unterscheidung der zwei Faelle (Upgrade ohne Konflikte und Upgrade mit Konfliken), die es bei Upgrade technisch bedingt gibt.

Den besseren Vergleich finde ich diesen:

- upgrade ist wie `mv -n', das nie ueberschreibt
- full-upgrade ist wie `mv -i', das mich entscheiden laesst aber keine Unterscheidung trifft ob es normale oder potenziell genauer zu bedenkende Faelle sind

Im Falle eines Testing/Unstable macht full-upgrade aus meiner Sicht schon Sinn, aber bei einem Stable will ich gerne den Fall Security-Updates einzuspielen trennen von dem Fall invasiver Aenderungen, weil ich bei ihnen unterschiedlich aufmerksam sein will. Diese Trennung bietet mir upgrade.

[reox]

Nur damit nicht ganz aneinander vorbei geredet wird... Natürlich muss man bei einem release upgrade irgendwann mal full-upgrade/dist-upgrade ausführen.
Wenn man das tut, sollte man die Liste der zu entfernenden Pakete genau studieren und ggf den Upgradevorgang abbrechen (genau so wie man die apt-listchanges ansehen sollte oder man vllt auch apt-listbugs).

Manchmal reicht es dann schon, das Paket was er da entfernen will auf manual zu setzen oder man muss halt schauen was da los ist.

Ich glaube jetzt die eine Möglichkeit wieder gefunden zu haben:

Code: Alles auswählen

# apt -o Debug::pkgProblemResolver=yes full-upgrade

Aber ich kann es mangels Konflikte nicht testen...

https://manpages.debian.org/bullseye/ap ... CHOPTIONEN

•Debug::pkgProblemResolver schaltet die Ausgabe über die von dist-upgrade, upgrade, install, remove, purge getroffenen Entscheidungen ein.

[fischig]

Einige hier machen Debian komplizierter als es ist.
Ihr solltet zwei Dinge immer mit angeben wenn ihr von upgrade vs. full-/dist-upgrade schreibt:
1. um welches release geht es: testing/sid ist kein stable. Das sind rolling releases und für solche gelten naturgemäß von vornherein andere Überlegungen als für stable.
2. wenn's um stable geht: geht's um die Aktualisierung des installierten Systems (dann habe ich bisher noch nichts gesehen, was die Nützlichkeit/Überlegenheit vom einfachen upgrade gegenüber full-/dist-upgrade zeigen könnte) oder geht's um einen Releasesprung, dann ist das einfache upgrade per se unbrauchbar.

Wenn man diese beiden Informationen weglässt, kann man natürlich wunderbar weiter aneinander vorbei reden.

[tscott]

....Wenn man diese beiden Informationen weglässt, kann man natürlich wunderbar weiter aneinander vorbei reden.

Deshalb heißt es ja auch "'apt' - Fragen, Erkennen und Verstehen". Es gibt zwar einn konkretes Problem bei einem Releasesprung. Hier in unserem Beispiel Buster auf Bullseye. Klar, nur da macht ein 'apt full-update' Aufruf Sinn. Aber eigentlich dachte ich geht es hier generell darum 'apt' endlich mal zu verstehen. Vor allem auch den Umgang damit bei Konflikten ohne konkrete Einzelfallprobleme näher zu beleuchten.

...man die apt-listchanges ansehen sollte oder man vllt auch apt-listbugs

Sieht nach sinnvollen Tools aus. Warum kann das aptitude nicht?

Ich glaube jetzt die eine Möglichkeit wieder gefunden zu haben:

Code: Alles auswählen

# apt -o Debug::pkgProblemResolver=yes full-upgrade

Aber ich kann es mangels Konflikte nicht testen...

https://manpages.debian.org/bullseye/ap ... CHOPTIONEN

•Debug::pkgProblemResolver schaltet die Ausgabe über die von dist-upgrade, upgrade, install, remove, purge getroffenen Entscheidungen ein.

Verstehe ich nicht ganz. Was meinst du mit "schaltet die Ausgabe ... ein"?