Vollständige Paketdeinstallation - aber wie?

[MSfree]

Bei mir zeigt Deborphan (nach dem Dist-Upgrade von Bullseye auf Bookworm) an ...

Genau diese Pakete räumt

Code: Alles auswählen

apt autopurge

auf. Deborphan benötigt man eigentlich nicht mehr, weil diese Information auch ein simulierter Lauf mit

Code: Alles auswählen

apt autopurge -s

liefert.

[rockyracoon]

Bei mir zeigt Deborphan (nach dem Dist-Upgrade von Bullseye auf Bookworm) an ...

Genau diese Pakete räumt

Code: Alles auswählen

apt autopurge

auf. Deborphan benötigt man eigentlich nicht mehr, weil diese Information auch ein simulierter Lauf mit

Code: Alles auswählen

apt autopurge -s

liefert.

Wieder ein Thx!
Wenn ich "apt autopurge" oder auch "apt autopurge -s" eingegeben habe und danach deborphan abrufe, dann zeigen sich aber die Paktelisten

gstreamer1.0-packagekit
libproxy1-plugin-gsettings
libproxy1-plugin-networkmanager
libproxy1-plugin-webkit

immer noch.
Laienhaft vermute ich, dass deborphan ein "false positiv" angibt, die Löschung dieser Daten daher ein Fehler wäre.
Und im Bezug zum Thread bedeutet das imho: "Don`t Overdo".

[dasebastian]

Deborphan benötigt man eigentlich nicht mehr, weil diese Information auch ein simulierter Lauf mit

Code: Alles auswählen

apt autopurge -s

liefert.

Ich kann nicht bestätigen, dass apt (autopurge) in der gleichen Weise nach Waisen sucht.

Das merke ich bei mir nach einer Neuinstallation. Wenn alles sauber und fertig ist, gibt es auch keine autopurges mehr. deborphan liefert mir dann aber noch ein paar Hinweise.

Übrigens kann man es ein paar mal durchlaufen lassen, es kann die weiteren Waisen erst erkennen, wenn du diese zu Waisen gemacht hast

[hikaru]

Spannend war da eher schon mein alter EeePC mit 1GB RAM und 4GB Flash. Da muß man schon ein paar Register ziehen, um mit 4GB Flash auszukommen. Bookworm mit Firefox, Thunderbird, gimp und LXDE habe ich da (dank Kompression auf Dateisystemebene mit btrfs) auf nur 1.7GB Flash gepreßt.

Da freut sich aber die CPU, die ohnehin schon keucht, wenn sie auch noch ein Dateisystem live (De-)Komprimieren darf. Da würde ich eher eine SD-Karte hernehmen um den Speicherplatz zu erweitern.

[dasebastian]

War bei mir selber vor nicht allzu langer Zeit ein Thema (EDIT: in offenem Thread offtopic plaudern) :

Die eigentliche Frage war, WIE Kry sämtliche Pakete wieder los wird, wenn diese zwar durch Programm A mitinstalliert wurden aber durch Programm B auch referenziert sind...

[hikaru]

Die eigentliche Frage war, WIE Kry sämtliche Pakete wieder los wird, wenn diese zwar durch Programm A mitinstalliert wurden aber durch Programm B auch referenziert sind...

Wie gesagt, die beste Chance ist, über apt.history nachzuvollziehen, was wann warum installiert wurde - was natürlich umso komplexer wrd, je länger die installation von A her ist, bzw. je mehr Installations- und Deinstallationsschritte seitdem passiert sind.
Prinzipiell ist das aber rein deterministisch*, d.h., ein Lösungsweg sollte sich eigentlich scripten lassen.

*) Vorausgesetzt, man hat nicht zwischendurch an apt vorbeigepfuscht (z.B. mit dpkg).

[tobo]

Wenn's kalt ist und Interesse an allen installierten Paketen - ohne harte Abhängigkeiten - besteht, dann könnte man sowas machen:

Code: Alles auswählen

$ for p in `aptitude search ~M -F%p`;do aptitude why "$p" | tail -1 | tr -s " " | grep -P '(?<!Depends)'" $p( |$)" --color=yes; done

[dasebastian]

Und man könnte (sofern installiert)

Code: Alles auswählen

aptitude why PAKET

fragen, womit die Reste zusammenhängen.

EDIT: Sorry tobo, gerade gesehen, das läuft bei deinem Tipp schon mit.

[MSfree]

Da freut sich aber die CPU, die ohnehin schon keucht, wenn sie auch noch ein Dateisystem live (De-)Komprimieren darf.

Zumindest der EeePC 901 mit Atom N270 kommt damit noch einigermassen klar. Wunder darf man aber nicht erwarten.

Da würde ich eher eine SD-Karte hernehmen um den Speicherplatz zu erweitern.

Leider ist der Kartenleser sogar noch langsamer als ein komprimiertes Dateisystem auf dem internen Flash.

[hikaru]

Zumindest der EeePC 901 mit Atom N270 kommt damit noch einigermassen klar. Wunder darf man aber nicht erwarten.

Der N270 hat eigentlich schon mehr als genug damit zu tun, überhaupt einen modernen Firefox zu starten. Wenn er zusätzlich beim Laden der Daten auch noch das Dateisystem dekomprimieren muss, wird das auf keinen Fall besser.

Leider ist der Kartenleser sogar noch langsamer als ein komprimiertes Dateisystem auf dem internen Flash.

Den internen Kartenleser des 901 hatte ich vor geraumer Zeit mal mit ca. 18MB/s gemessen, wenn ich mich richtig erinnere. Viel mehr (20-25MB/s?) gaben die SSDs (original 4+8GB, sowie nachgerüstete 2. 64GB-SSD) unkomprimiert auch nicht her.
Der Flaschenhals des 901 war für mich jedenfalls immer die CPU, nie die Datenträger. Seit Buster hat das für mich subjektiv die Grenze zur Unbenutzbarkeit überschritten, was wohl einerseits an gestiegenen Anforderungen der Software, andererseits an gestiegener Erwartungshaltung meinerseits liegt, weil ich den 901 inzwischen durch einen GPD MicroPC ersetzt habe, der natürlich Kreise um den EEE dreht.

[Blackbox]

Beim Deaktivieren des Swap geht, soviel ich glaube zu wissen, aber die Bereitschaftsfunktion nicht mehr.

Kann es sein, dass hier eine Verwechslung vorliegt?
Ansonsten wäre diese Annahme Unsinn, die hier behauptet wird.

[novalix]

apt autoremove entfernt alle Pakete, die keinen "Installationsgrund" mehr haben. Ein Installationsgrund eines Pakets B ist ein Paket A, welches B als Abhängigkeit (Dependency), Empfehlung (Recommendation) oder Vorschlag (Suggestion) referenziert.
Wenn du nun A installierst, welches B als Abhängigkeit mitbringt und du daraufhin A wieder deinstallierst, dann wird apt autoremove B nicht deinstallieren, wenn es z.B. vom ebenfalls installierten Paket C als Empfehlung referenziert wird.
Wenn du gewohnheitsmäßig Pakete ohne Empfehlungen und Vorschläge installierst um dein System schlank zu halten, dann wirst du über wiederholte Paketinstallationen und -deinstallationen trotzdem Empfehlungen und Vorschläge ansammeln, wenn sie von einstmals installierten Paketen als Abhängigkeiten referenziert werden.

Das ist leider ein Schwachpunkt im Design von Debians Paketmanagement für den keine Standardlösung vorgesehen ist. Du kannst dir aber behelfen, indem du in /var/log/apt.history nachschaust, welche Pakete bei der Installation eines Pakets A tatsächlich installiert wurden und dann gezielt die ganze Liste der Abhängigkeiten deinstallieren. Falls du seitdem weitere Pakete installiert hast, kann es aber zu Überschneidungen kommen. Daher solltest du genau hinschauen, was tatsächlich passiert.

Es könnte sein, dass sich das Verhalten des Paketmanagement ändert, wenn man die allgemeine Konfiguration anpasst.
Per Default werden empfohlene Pakete mit installiert. Im konkreten Szenario wird dieses grundsätzliche Verhalten per Kommandozeilenoption bei der Installation überschrieben. Bei allen nachfolgenden Aktionen gilt aber wieder die allgemeine Konfiguration.

[hikaru]

Es könnte sein, dass sich das Verhalten des Paketmanagement ändert, wenn man die allgemeine Konfiguration anpasst.
Per Default werden empfohlene Pakete mit installiert. Im konkreten Szenario wird dieses grundsätzliche Verhalten per Kommandozeilenoption bei der Installation überschrieben. Bei allen nachfolgenden Aktionen gilt aber wieder die allgemeine Konfiguration.

Nein, leider nicht. Ich installiere alles ohne Empfehlungen und Vorschläge, per Option in apt.conf. Ich muss also die Option nicht mehr explizit bei apt-Kommandos angeben.
Das ändert aber Nichts daran, dass eine Empfehlung oder ein Vorschlag dafür sorgt, dass einmal automatisch installierte Pakete weiterhin einen Installationsgrund haben.

[dasebastian]

... ändert aber Nichts daran, dass eine Empfehlung oder ein Vorschlag dafür sorgt, dass einmal automatisch installierte Pakete weiterhin einen Installationsgrund haben.

Das ist schön zusammengefasst. Ein Recommend/Suggest woanders sollte eigentlich kein Grund sein, etwas zu behalten - bzw. sollten diese mit dem eigentlichen Install verknüpft sein und nicht mit jenen Programmen, die OHNE es installiert wurden. Das ist vom Ergebnis her irgendwie, als würde ich die Recommends/Suggests automatisch mit apt-mark als manual markiert haben...

[novalix]

Ein Recommend/Suggest woanders sollte eigentlich kein Grund sein, etwas zu behalten - bzw. sollten diese mit dem eigentlichen Install verknüpft sein und nicht mit jenen Programmen, die OHNE es installiert wurden. Das ist vom Ergebnis her irgendwie, als würde ich die Recommends/Suggests automatisch mit apt-mark als manual markiert haben...

Klammern wir doch die suggests mal aus. Die werden eh nicht automatisch installiert, wenn man das nicht ausdrücklich so will.
In dem Fall, wo die voreingestellte Konfiguration lediglich per CLI-Option überschrieben wird, würde ich das Verhalten von apt als konsistent und erwartbar einstufen.
Bei geänderter globaler Konfiguration eher nicht. Gibt es dafür einen Bug-Report?

[hikaru]

In dem Fall, wo die voreingestellte Konfiguration lediglich per CLI-Option überschrieben wird, würde ich das Verhalten von apt als konsistent und erwartbar einstufen.
Bei geänderter globaler Konfiguration eher nicht. Gibt es dafür einen Bug-Report?

Soweit ich weiß, gibt es dazu keinen Bugreport. Ich sehe das aber auch nicht als Bug, denn ich würde es ebenso unerwartet empfinden, wenn sich die Option per CLI-Schalter anders verhalten würde als per Konfigurationsdatei.

[tobo]

In dem Fall, wo die voreingestellte Konfiguration lediglich per CLI-Option überschrieben wird, würde ich das Verhalten von apt als konsistent und erwartbar einstufen.
Bei geänderter globaler Konfiguration eher nicht. Gibt es dafür einen Bug-Report?

Soweit ich weiß, gibt es dazu keinen Bugreport. Ich sehe das aber auch nicht als Bug, denn ich würde es ebenso unerwartet empfinden, wenn sich die Option per CLI-Schalter anders verhalten würde als per Konfigurationsdatei.

Und vor allem hat es damit überhaupt nichts zu tun - (Auto)Remove ist ja völlig unabhängig vom Install und hat auch überhaupt keine Informationen darüber, wie das irgendwann mal installiert wurde. Das Verhalten ist also auch so, wenn beide oder keine der Optionen gesetzt ist oder wenn Suggests, beim Installieren, explizit aktiviert wurde.

[MSfree]

Und vor allem hat es damit überhaupt nichts zu tun - (Auto)Remove ist ja völlig unabhängig vom Install und hat auch überhaupt keine Informationen darüber, wie das irgendwann mal installiert wurde.

Wenn Pakete über die Recommends oder Suggests installiert werden, dann sieht es so aus, daß autopurge diese eben nicht findet und nicht deinstalliert, wenn das Elternpaket, das diese Recommends/Suggents verursacht hat, deinstalliert wird. Solche Pakete gelten wohl als menuell installiert. Lustig finde ich aber, daß deborphan solche Pakte dann doch findet, irgendeinen Informationsunterschied scheint deborphan dann doch auszunutzen.

[dasebastian]

Lustig finde ich aber, daß deborphan solche Pakte dann doch findet, irgendeinen Informationsunterschied scheint deborphan dann doch auszunutzen.

Ich weiss gar nicht, ob deborphan genau diese Pakete findet, das habe ich so nie explizit ausprobiert...

[tobo]

Und vor allem hat es damit überhaupt nichts zu tun - (Auto)Remove ist ja völlig unabhängig vom Install und hat auch überhaupt keine Informationen darüber, wie das irgendwann mal installiert wurde.

Wenn Pakete über die Recommends oder Suggests installiert werden, dann sieht es so aus, daß autopurge diese eben nicht findet und nicht deinstalliert, wenn das Elternpaket, das diese Recommends/Suggents verursacht hat, deinstalliert wird. Solche Pakete gelten wohl als menuell installiert.

Nein, die sind dann auch automatisch installiert, haben aber keine Abhängigkeit.

Lustig finde ich aber, daß deborphan solche Pakte dann doch findet, irgendeinen Informationsunterschied scheint deborphan dann doch auszunutzen.

deborphan wird das grundsätzlich nicht viel anders machen, als ich das 1 Seite zuvor gezeigt habe. Das ist keine Magie...

[JTH]

Lustig finde ich aber, daß deborphan solche Pakte dann doch findet, irgendeinen Informationsunterschied scheint deborphan dann doch auszunutzen.

deborphan wird das grundsätzlich nicht viel anders machen, als ich das 1 Seite zuvor gezeigt habe. Das ist keine Magie...

Hmm, das hat mich gerade gewundert, musste direkt auf meinem Desktop mal nachschauen. Hier gibt deborphan, ohne extra Optionen, zwei Übergangspakete (enthalten „transitional package“ in der Beschreibung) und zwei -dev-Pakete aus. Alle vier als manuell installiert markiert.

Ich nehme mal an, dass deborphan also u.a. nach „transitional package“ und verwandten Strings sucht und vielleicht davon ausgeht, dass der „normale“ Benutzer keine -dev-Pakete braucht.

[MSfree]

Nein, die sind dann auch automatisch installiert, haben aber keine Abhängigkeit.

Das war eine Vermutung von mir.

deborphan wird das grundsätzlich nicht viel anders machen, als ich das 1 Seite zuvor gezeigt habe. Das ist keine Magie...

Grundsätzlich haben alle installierten Pakete einen Referencecounter. Wenn man ein Paket installiert, das von einem bereits instalierten Paket abhängig ist, wird der Refcounter für das abhängie Paket hochgezählt. Beim Deinstallieren wird dieser Refcouter wieder dekrementiert und sobald der auf Null steht, kann man es mit autopurge entfernen. Manuell installierte Pakete bekommen einfach den Refcount 1 bei der Installation, der Refcounter kann also nie unter 1 fallen und somit bleibt es beim autopurge auf der Platte.

deborphan bedient sich aber irgendwelcher zusätzlicher Informationen, denn sonst dürfte autopurge und deborphan keinen Unterschied ergeben.

[tobo]

Gerade auch mal getestet - deborphan findet Pakete, die haben mit der Fragestellung hier überhaupt nichts zu tun. Bei mir zeigt es z.B. rxvt-unicode-256color an, was von mir manuell installiert wurde und auch nicht als automaitsch installiert gelistet ist.

[JTH]

Grundsätzlich haben alle installierten Pakete einen Referencecounter. Wenn man ein Paket installiert, das von einem bereits instalierten Paket abhängig ist, wird der Refcounter für das abhängie Paket hochgezählt. Beim Deinstallieren wird dieser Refcouter wieder dekrementiert und sobald der auf Null steht, kann man es mit autopurge entfernen. Manuell installierte Pakete bekommen einfach den Refcount 1 bei der Installation, der Refcounter kann also nie unter 1 fallen und somit bleibt es beim autopurge auf der Platte.

Das würde mich wundern, wenn das tatsächlich so „kompliziert“ implementiert ist. Damit würde ein Deinstallation per dpkg nämlich auch einen gedachten Referenzzähler, den apt verwaltet, völlig durcheinanderbringen.

Es gibt /var/lib/apt/extended_states – da steht einfach für jedes Paket drin, ob es automatisch installiert wurde. Einen anderen, gespeicherten Zustand kenn ich da nicht. Hast du eine Quelle für deine Beschreibung, MSfree?

deborphan bedient sich aber irgendwelcher zusätzlicher Informationen, denn sonst dürfte autopurge und deborphan keinen Unterschied ergeben.

Ich vermute eher, es sind einfach ein paar Heuristiken, die auf die vorhandenen Datenbanken von dpkg und apt angewandt werden – keine irgendwo zusätzlich gespeicherten und alleine von/für deborphan verwalteten Informationen.

zeigt es z.B. rxvt-unicode-256color an

Ist ein „dummy transitional package for rxvt-unicode“. Siehe mein voriger Beitrag.

[dasebastian]

Mal kurzer Einwurf:
Ich habe deborphan ziemlich zu Beginn nur als eine zusätzliche Idee eingeworfen, nicht gewollte Pakete zu identifizieren. Nicht mehr, nicht weniger.

Wenn wir das weiter diskutieren wollen, sollten wir hier (irgendwo) (TM) vielleicht mal abtrennen?