Wie weit kann man Debian testing bei autoremove trauen?

[Ravenbird]

Ich habe hier auf dem Rechner Debian testing am laufen und bin damit soweit auch sehr zufrieden. Natürlich fällt mir auf das ich immer wenn ich mit APT Programme installiere, deinstalliere oder aktualisiere eine riesige Liste an Paketen kommt bei denen empfohlen wird sie via autoremove zu entfernen. Das sieht dann z. B. so aus:

Code: Alles auswählen

Die folgenden Pakete wurden automatisch installiert und werden nicht mehr benötigt:
docutils-common docutils-doc espeak-data ethtool firebird2.5-common
firebird2.5-common-doc firebird2.5-server-common firebird3.0-common
firebird3.0-common-doc gdebi-core gstreamer0.10-alsa
gstreamer0.10-plugins-base libalgorithm-c3-perl libamd2.3.1
libarchive-extract-perl libasprintf0c2 libavcodec56 libavformat56
libavresample2 libavutil54 libb-hooks-endofscope-perl
libbasicusageenvironment0 libbind9-90 libboost-system1.55.0 libcamd2.3.1
libccolamd2.8.0 libcholmod2.1.2 libchromaprint0 libclass-c3-perl
libclass-c3-xs-perl libclass-method-modifiers-perl libclass-xsaccessor-perl
libcolamd2.8.0 libcpan-changes-perl libcpan-meta-perl libdata-optlist-perl
libdata-perl-perl libdata-section-perl libdbus-1-dev libdevel-caller-perl
libdevel-globaldestruction-perl libdevel-lexalias-perl libdiscid0 libdns100
libdumbnet1 libdvbpsi9 libegl1-mesa-drivers libelfg0 libenca0 libept1.4.12
libespeak1 libexporter-tiny-perl libfbclient2 libfbembed2.5 libfglrx
libfile-slurp-perl libfreerdp-cache1.1 libfreerdp-client1.1
libfreerdp-codec1.1 libfreerdp-common1.1.0 libfreerdp-core1.1
libfreerdp-crypto1.1 libfreerdp-gdi1.1 libfreerdp-locale1.1
libfreerdp-primitives1.1 libfreerdp-rail1.1 libfreerdp-utils1.1 libgconf2-4
libgegl-0.2-0 libgetopt-long-descriptive-perl libgif4 libgles1-nvidia
libgles2-nvidia libglew1.10 libgphoto2-port10 libgroupsock1
libgstreamer-plugins-base0.10-0 libgstreamer-vaapi1.0-0 libgstreamer0.10-0
libhunspell-1.3-0 libical1a libilmbase6 libimobiledevice4
libimport-into-perl libintl-perl libintl-xs-perl libio-stringy-perl libisc95
libisccc90 libisccfg90 libjasper1 libjim0.75 libjpeg-turbo-progs
libkeybinder0 liblircclient0 liblist-moreutils-perl liblivemedia23
libllvm3.5 liblog-message-perl liblog-message-simple-perl liblouis2
liblwres90 libmodule-build-perl libmodule-implementation-perl
libmodule-load-conditional-perl libmodule-pluggable-perl
libmodule-runtime-perl libmodule-signature-perl libmoo-perl
libmoox-handlesvia-perl libmro-compat-perl libnamespace-autoclean-perl
libnamespace-clean-perl libnl-route-3-200 libnm-glib-vpn1 libnm-glib4
libnm-gtk-common libnm-gtk0 libnm-util2 libntdb1 libopenexr6 libopenjpeg5
libopenraw1 libopenvg1-mesa liborcus-0.8-0 libpackage-constants-perl
libpackage-stash-perl libpackage-stash-xs-perl libpadwalker-perl
libparams-classify-perl libparams-util-perl libparams-validate-perl
libpath-tiny-perl libperl4-corelibs-perl libplist2 libpng12-0
libpod-latex-perl libpod-markdown-perl libpod-readme-perl libpoppler46
libpostproc52 libpth20 libqmi-glib1 libqpdf13 libqt4-dbus libqt4-xml
libqtcore4 libqtdbus4 libqtgui4 libregexp-common-perl libreoffice-gtk
libreoffice-sdbc-firebird librole-tiny-perl libschroedinger-1.0-0 libsctp1
libsoftware-license-perl libstrictures-perl libsub-exporter-perl
libsub-exporter-progressive-perl libsub-identify-perl libsub-install-perl
libswscale3 libterm-ui-perl libtext-soundex-perl libtext-template-perl
libtommath1 libtry-tiny-perl libturbojpeg0 libturbojpeg1 libtype-tiny-perl
libtype-tiny-xs-perl libumfpack5.6.2 libunicode-utf8-perl
libusageenvironment1 libusbmuxd2 libuuid-perl libva-glx1
libvariable-magic-perl libvncclient0 libvpx1 libvte-2.90-9
libvte-2.90-common libvte-common libvte9 libwebp5 libwebpdemux1 libwebpmux1
libwebrtc-audio-processing-0 libwinpr-crt0.1 libwinpr-crypto0.1
libwinpr-dsparse0.1 libwinpr-environment0.1 libwinpr-file0.1
libwinpr-handle0.1 libwinpr-heap0.1 libwinpr-input0.1
libwinpr-interlocked0.1 libwinpr-library0.1 libwinpr-path0.1
libwinpr-pool0.1 libwinpr-registry0.1 libwinpr-rpc0.1 libwinpr-sspi0.1
libwinpr-synch0.1 libwinpr-sysinfo0.1 libwinpr-thread0.1 libwinpr-utils0.1
libwps-0.3-3 libx264-142 libxapian22 libxcb-composite0 libxerces-c3.1
libxfce4util6 libxfcegui4-4 libxml-security-c17v5 lksctp-tools pkg-config
python-cddb python-cups python-dbus-dev python-defusedxml python-docutils
python-imaging python-musicbrainz2 python-pexpect python-pil
python-ptyprocess python-pygments python-renderpm python-reportlab
python-reportlab-accel python-roman python-smbc python-soappy python-wstools
qdbus qt-at-spi qtchooser qtcore4-l10n vlc-nox xfce-keyboard-shortcuts
xfce4-artwork xfce4-quicklauncher-plugin xfce4-volumed xscreensaver
xscreensaver-data zerofree
Verwenden Sie »sudo apt autoremove«, um sie zu entfernen.

Dabei stellt sich mir nun die Frage ob APT da jetzt hohl dreht, den da sind doch diverse Pakete dabei die ich identifizieren kann und deren Entfernung keine guten Folgen haben würden.

Weiß einer von Euch wo da das Problem liegt? Finde das ziemlich nervig und hätte gerne den Grund für die ganze Sache in den Griff bekommen.

[Korodny]

Was steht denn in /etc/apt/sources.list ?

[Radfahrer]

Das hängt mit Metapaketen und Abhängigkeiten zusammen. Wenn du z.B. den Gnome-Desktop installierst und dann ein einzelnes Paket daraus wieder entfernst, will autoremove alle anderen Pakete, die das entfernte als Abhängigkeit haben, auch entfernen.

Dazu gibt es hier im Forum reichlich Threads. Einfach mal suchen und schlau machen über Abhängigkeiten und Metapakete.
Mit der sources.list hat das nichts zu tun. Das ist eine Eigenschaft der Paketverwaltung.

z.B.
viewtopic.php?f=27&t=126016

[dufty2]

Man kann debians autoremove nur bedingt trauen.

Hatte mein testing-kiste mit knapp 3000 Paketen vollgeschaufelt und jetzt wieder bei weniger als die Hälfte.
War ein mehrstufiger Prozess

Grundsätzlich versuchen, das System schlank zu halten.
Dann kann mal was neues ausprobieren um es nach konsequent 1 Monat wieder löschen (bei Nichtgefallen).

Tut man das nicht, und gar noch ein paar sid-, experimental-, stable- und non-debian Pakete reinpressen,
könnte das Ungemach bereiten ...

[breakthewall]

Ich habe hier auf dem Rechner Debian testing am laufen und bin damit soweit auch sehr zufrieden. Natürlich fällt mir auf das ich immer wenn ich mit APT Programme installiere, deinstalliere oder aktualisiere eine riesige Liste an Paketen kommt bei denen empfohlen wird sie via autoremove zu entfernen. Das sieht dann z. B. so aus:

Dabei stellt sich mir nun die Frage ob APT da jetzt hohl dreht, den da sind doch diverse Pakete dabei die ich identifizieren kann und deren Entfernung keine guten Folgen haben würden.

Weiß einer von Euch wo da das Problem liegt? Finde das ziemlich nervig und hätte gerne den Grund für die ganze Sache in den Griff bekommen.

Grundsätzlich ist diese Funktion mit Vorsicht zu geniessen, und sollte niemals ausgeführt werden ohne genaue Prüfung. Das ist besonders dann der Fall, wenn man sein Debian mit einem vom Installer vorgegebenen Desktop installiert hat. Das ist gängige Praxis und dient dazu, dem Nutzer bereits ab Installation eine sinnvolle und funktionale Softwareumgebung anbieten zu können. Daher werden sogenannte Metapakete geschnürt, die viele Pakete als Abhängigkeiten angeben, wie auch einzelne Pakete darunter wiederum eigene vorgeschlagene Abhängigkeiten, bzw. mitunter sinnvolle Ergänzungen zusätzlich installieren.

Nun entsteht folgendes Problem:
Wenn man nun anfängt an diesen Komplettpaketen herumzubasteln, dann langt mitunter ein Paket und APT will einem sogleich den halben Desktop und noch mehr entfernen. Rein aus Sicht des Paketmanagers und der Abhängigkeiten ist das auch richtig und logisch, weil alle Pakete die mittels Metapaketen installiert werden miteinander verbunden sind, und somit automatisch als Abhängigkeit installiert wurden. Und ein autoremove entfernt ausschließlich Pakete die automatisch installiert wurden. Will man also ein GNU/Linux nach eigenen Vorstellungen errichten, sollte man die Finger von diesen Komplettpaketen lassen. Das Dilemma lässt sich theoretisch zwar lösen, indem man verantwortliche Metapakete identifiziert, löscht und dann alle Pakete im System als manuell installiert markiert, doch das ist eine lästige und keine saubere Lösung.

Lösung des Problems:
Niemals Komplettpakete installieren. Sprich, schon im Installer keinen Desktop zur Installation auswählen, und lediglich das Grundsystem installieren. Danach kann man in das installierte System booten, und fügt nun manuell hinzu was man wirklich haben will, was jedoch wieder Wissen vorraussetzt was entsprechende Komplettpakete komplett abnehmen. Will man nun Pakete entfernen, hat man das Problem mit autoremove erst gar nicht, weil der Desktop und alles was noch hinzu kam manuell installiert wurden, womit nur entfernt werden würde was effektiv nicht ohne andere Pakete funktionieren kann. Man sollte sich hier eingehender damit befassen, was einzelne Pakete so alles benötigen, bevor man anfängt Pakete zu löschen.

[jph]

Wenn du gerade das Upgrade von Stable auf Testing durchgeführt hast, ist eine große Menge von obsoleten Paketen normal. Das sind zumeist Pakete, die im neuen Release nicht mehr oder mit anderem Namen enthalten sind.

[Korodny]

Mit der sources.list hat das nichts zu tun.

Seine Aussage war, dass da Pakete dabei wären, "deren Entfernung keine guten Folgen haben würden". Das kann entweder daran liegen, dass er sich schon sehr lange nicht mehr um die Entfernung überflüssiger Pakete gekümmert hat (wegen der Menge der Einträge) und die überflüssigen Pakete schlicht bereits durch welche mit neuerer Versionsbezeichnung ersetzt wurde - oder daran, dass er versehentlich die sources.list um falsche Repositories ergänzt hat (unstable, irgendwelche Drittanbieter...).

Deswegen meine Frage nach der sources.list - ob man apt "trauen" kann, hängt m.E. (zusätzlich zu den anderen im Thread genannten Punkten) von den benutzten Repositories ab.

[Radfahrer]

@korodny
Das Problem mit den Abhängigkeiten und Metapaketen tritt auch auf, wenn man ausschließlich das main-Repository in der sources.list hat.
Zumal es eher unwahrscheinlich ist, dass Fremdrepos Metapakete installieren.

Die wahrscheinlichste Ursache ist der Desktop, da dieser sehr viele Pakete als Abhängigkeiten hat. Deinstalliert man eines davon, holt autoremove zum Kahlschlag aus.

Ich benutze übrigens autoremove überhaupt nicht. Ich nutze lieber deborphan und debfoster.

[uname]

Das Tolle an der autoremove-Funktion ist, dass niemals das gesamte System zerstört wird. Es kann natürlich sein, dass z.B. der gesamte Gnome-Desktop deinstalliert wird. Aber das System wird immer mindestens in der Konsole lauffähig bleiben. Ok der deine oder andere wird vielleicht Probleme mit dem Internet bekommen, da dieses per WLAN und GUI konfiguriert wird. Aber sonst passiert meistens nicht. Und wenn doch mal essentiell wichtige Pakete deinstalliert werden sollen wird man in der Form gewarnt, dass man nicht nur mit einem Buchstaben (Y/J), sondern mit einem Satz diese Aktion bestätigen muss. Leider ist mir der genaue Wortlaut entfallen. Somit kann eigentlich fast nichts passieren.

Ach ja:
Es macht im übrigen bei einem Deskop-Wechsel Sinn erst den neuen Desktop zusätzlich zu installieren und dann den alten Desktop zu deinstallieren, um Löschen und Installieren identischer Pakete zu verhindern. Das spart am Ende Zeit auch wenn das Ergebnis identisch ist. Auch kann man dann wahrscheinlich alles direkt per GUI (alte GUI zur Installation, neue GUI zur Deinstallation) durchführen. Selbst das GUI-WLAN sollte nicht kaputt gehen.

[hikaru]

Es macht im übrigen bei einem Deskop-Wechsel Sinn erst den neuen Desktop zusätzlich zu installieren und dann den alten Desktop zu deinstallieren, um Löschen und Installieren identischer Pakete zu verhindern. Das spart am Ende Zeit auch wenn das Ergebnis identisch ist.

Das Ergebnis ist nur dann identisch, wenn apt Recommends und Suggests standardmäßig mitinstalliert (was die Voreinstellung ist).
Hat man diese Voreinstellung geändert, dann würde das Installieren des neuen Desktops vor Entfernen des Alten bereits installierte Recommends und Suggets erhalten, während die Deinstallation des Alten und anschließende Installation des Neuen Recommends und Suggests bei einem dazwischenliegenden autoremove entfernt.

[tobo]

Das Ergebnis ist nur dann identisch, wenn apt Recommends und Suggests standardmäßig mitinstalliert (was die Voreinstellung ist).

Bislang war die Voreinstellung doch immer nur Recommends, oder?

Hat man diese Voreinstellung geändert, dann würde das Installieren des neuen Desktops vor Entfernen des Alten bereits installierte Recommends und Suggets erhalten, während die Deinstallation des Alten und anschließende Installation des Neuen Recommends und Suggests bei einem dazwischenliegenden autoremove entfernt.

Seit wann entfernt autoremove Recommends und Suggests? Auch das ist mir neu!? Ist das seit Stretch so oder hab' ich da was verpasst?

[hikaru]

Bislang war die Voreinstellung doch immer nur Recommends, oder?

Seit Squeeze(?) werden standardmäßig auch Suggests installiert.

Seit wann entfernt autoremove Recommends und Suggests? Auch das ist mir neu!? Ist das seit Stretch so oder hab' ich da was verpasst?

Das ist wohl ein Missverständnis. Da es hier im Thread um autoremove geht, ging ich davon aus, dass das Teil jeder diskutierten Aktion ist.
So ging ich auch davon aus, dass uname nach dem Deinstallieren seines alten Desktops ein autoremove ausführt. Wenn er den alten Desktop deinstalliert, nachdem er den Neuen installiert hat, dann entfernt ein anschließendes autoremove nur die Pakete, die vom alten Desktop automatisch installiert wurden, vom Neuen aber nicht referenziert werden.

Dreht er die Reihenfolge um (erst Deinstallation+autoremove, dann Installation), dann ist es wichtig, ob er zwischen der Installation des alten und des neuen Desktops seine apt-Konfiguration bezüglich Rec/Sug geändert hat und ob der erste Desktop Dependencies hatte, die für den neuen nur noch Rec/Suc sind.
Hat er den alten Desktop mit Rec/Sug installiert (wie es z.B. der Debian-Installer tut), dann die Rec/Sug-Installation deaktiviert, deinstalliert dann den alten Desktop (mit anschließendem autoremove) und installiert dann den neuen Desktop, dann werden Rec/Sug-Pakete des neuen Desktops nicht installiert.
Hätte er die ursprüngliche Reihenfolge von Desktop-Installation und -Deinstallation beibehalten, dann würden Pakete die bereits beim alten Desktop installiert waren und Rec/Sug des Neuen sind erhalten bleiben, denn sie hätten beim autoremove nach der Deinstallation des alten Desktops weiterhin einen Installationsgrund.

Streng genommen müsste man jetzt auch noch die Rolle alternativer Pakete als Dep/Rec/Sug betrachten, aber ich fürchte mein Beitrag ist schon konfus genug.
Als Fazit bleibt stehen, dass aus funktionaler Sicht die Deinstallation und Installation von Paketen im Allgemeinen nicht kommutativ ist.