[DE] Endgegner 'autoremove'

[samoht]

Die folgenden Pakete wurden automatisch installiert und werden nicht mehr benötigt:
 ...linux-headers-6.5.2-1-siduction-amd64
  linux-headers-6.5.3-1-siduction-amd64 linux-image-6.5.2-1-siduction-amd64
  linux-image-6.5.3-1-siduction-amd64
Verwenden Sie »apt autoremove«, um sie zu entfernen.

Hier leistet das aus dem siduction-Team stammende script

Code: [Select]

kernel-removereinen wertvollen Dienst

[hendrikL]

und bitte nehmt

Code: [Select]

apt autopurgebzw

Code: [Select]

apt autoremove --purge

[Isegrimm666]

• Also ich sehe zunächst ein apt upgrade und kein apt full-upgrade. 
• In der autoremove-Liste sehe ich keine Probleme. Wir sind schon beim Kernel 6.5.6-1. Der Rest sind ein paar nicht mehr benötigte libs. apt autoremove sollte save sein (und war es bei mir auch immer).
• Warum die Pakete zurückgehalten werden, musst du auf deiner Maschine klären. Siehe auch 1.

edlin

Guten Morgen ...

zu 1.: Das ist korrekt, da ich hier mal gelesen habe (und ich glaube, das Du selbst mir den Tipp gabst) dass ein full-upgrade erst dann gestartet werden sollte, wenn keine zurückgehaltenen Pakete mehr existieren. Wenn ich das jetzt falsch verstanden habe ... sorry.

(Warum eigentlich der " " ?

zu 3.: Das verstehe ich jetzt nicht. Wie kann ich das klären?

----------------

Ich werde heute abend, wenn ich wieder am Rechner bin, ein "apt autoremove --purge" durchführen, gefolgt von einem "apt full-upgrade".

(Es geht mir einfach darum einen Weg zu finden, mein System kontinuierlich zu pflegen und dabei möglichst sauber und fehlerlos zu arbeiten.  )

Isegrimm

[hendrikL]

Zu 1: da wir hier mit debian sid/unstable arbeiten und dieses sich stets weiter entwickelt, sollte immer ein "apt full-upgrade, dist-upgrade oder nala upgrade" durchgeführt werden. Es ändern sich immer wieder Programme und deren Abhängigkeiten.

Siehe: https://manual.siduction.org/sys-admin-apt_de.html#aktualisierung-des-systems

Zu 3: Nach einem erfolgreichen "full-upgrade", oder was bevorzugt wird, und die Pakete werden immer noch zurückgehalten (welches erst einmal kein Problem für das Funktionieren des Systems ist), kann man z. B. mit "apt -s install <zurückgehaltenes Päckchen>" schauen, wo es klemmt.

[edlin]

  , weil ich dachte, dass das Thema durch ist. Also nochmal: Der normale Ablauf für ein Upgrade sollte immer eine der folgenden Versionen sein:

Code: [Select]

apt update && apt full-upgrade
apt update && apt dist-upgrade
nala upgradeNatürlich mit root-Rechten.

Ein

Code: [Select]

apt upgrade macht nur in seltenen Fällen Sinn. Und das ist zum Beispiel bei einer Transition (Perl, Qt, ...) der Fall. Da kann es schon mal vorkommen, dass über 200 Pakete zum Entfernen vorgeschlagen werden. Will man in dieser Zeit, die schon mal etliche Tage umfassen kann, sein System wenigstens teilweise aktualisieren, ohne es zu schrotten, dann bietet sich ein upgrade an, da es keine Pakete entfernen wird. Das ist aber nur eine temporäre Notlösung. Alternativ kann man den Übeltäter auch temporär auf hold setzen. Infos gibts normalerweise in den Upgrade-Warnungen.

Wenn bei einem full-upgrade mal ein Paket gelöscht werden soll, muss man nicht gleich in Panik verfallen. Da sollte man schauen, ob es eine Anwendung ist, die man nicht gehen lassen möchte oder nur eine nicht mehr benötigte lib, die jetzt in einem Paket integriert wurde etc.
@hendrikL hat dir ja schon eine einfache Methode genannt, mit
apt -s install <Paketname> oder apt --simulate install <Paketname> gefahrlos nach Ursachen zu forschen.

Ich selbst bin ein Freund täglicher Upgrades, da sich dann auch nicht so viel anstaut. Bezüglich der Kernel wurdest du ja schon auf kernel-remover hingewiesen; allerdings empfiehlt es sich, immer noch eine ältere funktionierende Kernelversion vorzuhalten, um bei Problemen alternativ mit dem anderen Kernel booten zu können.

edlin

[eriefisher]

Personally I've never had an issue with autoremove but I do watch to see what's being remove. What I do find though is the amount of "junk" that gets left behind after a package has been removed. This is a one-liner I started using several years ago. I didn't write it but helps clean things up. I just named it apt-residual and call it when I want.

Code: [Select]

#!/bin/bash

#Purge  residual files. Need to be root.

apt-get purge $(dpkg -l | grep '^rc' | awk '{print $2}')
I'll run a dist-upgrade, an autoremove then apt-residual.

[ro_sid]

apt-get purge $(dpkg -l | grep '^rc' | awk '{print $2}')

Exactly the same can be accomplished by "apt-get --purge autoremove".
[And somewhere I have read "apt-get autopurge", but I do not see that in my man page of apt(-get).]

Me, I always did this with "aptitude" interactively ('~rc' searches for configuration files whose packages were deleted/removed).

[eriefisher]

I just did a d-u and it was good timing because there is a kernel upgrade. A good opportunity to test this out. After the d-u I rebooted into the new kernel. I immediately ran

apt --purge autoremove

which of course removed the older kernel etc.

I then ran the script I posted and was able to remove a config file from a previously removed kernel.

So, not exactly the same this it looks like.

[ro_sid]

@eriefisher: Yes, you are correct: The "apt --purge autoremove" removes only configuration files of packages, that it "touches/removes".
"Your" script removes all of them, regardless (old cruft, too).
But when you always(!) execute the "apt --purge autoremove" to eliminate unused packages, they lead to the same result .