Comment traiter `apt-get autoremove` dans Ubuntu
(Je peux énumérer plus de 20 pages avec un genre de questions/préoccupations similaires. Mais, je ne pouvais pas trouver de solution. Alors, s'il vous plait, patientez avec moi avant de marquer ceci en double.)
Cela fait presque trois semaines que je suis passé de Windows à Linux (Ubuntu). J'ai essayé de trouver les bons outils pour mes applications. J'ai donc essayé beaucoup d'applications différentes sous Linux. En conséquence, j'ai installé/supprimé de nombreuses applications à l'aide de _apt-get_.
Après l’une de ces commandes d’installation/suppression, _apt-get_ a suggéré d’exécuter la commande _apt-get autoremove_. C'est ce que j'ai fait, puis j'ai compris que certaines de mes applications de bureau avaient également été supprimées et l'apparence de mon environnement de bureau avait complètement changé. Comme je ne suis pas expert en Linux, j'ai fini par passer du temps à le réinstaller!
C'est alors que j'ai décidé de ne plus jamais utiliser _apt-get autoremove_. J'ai ensuite cherché et trouvé deborphan qui était recommandé pour supprimer les paquets Orphan. Ainsi, au lieu d’utiliser _apt-get autoremove_, j’utilisais la commande ci-dessous pour éliminer les paquets indésirables:
_Sudo deborphan --guess-all | xargs Sudo apt-get -y remove --purge
_C'était très bien jusqu'à récemment qu'après l'avoir exécuté, Qt-Creator a cessé de compiler mon code C++ avec l'erreur _cannot find -lGL_. C'était juste bien avant d'utiliser deborphan. Heureusement, j'ai pu résoudre ce problème en réinstallant le package _libgl1-mesa-dev_.
Donc, malheureusement, c’était aussi la fin de ma confiance en deborphan.
Maintenant, après quelques jours d'utilisation de ni de _apt-get autoremove_ ni de deborphan, voici la longue liste de paquets que apt suggère de supprimer:
_ 0 upgraded, 0 newly installed, 79 to remove and 0 not upgraded.> The following packages will be REMOVED: fonts-wine
geany-plugins-common gir1.2-evince-3.0 gir1.2-gconf-2.0
gir1.2-nautilus-3.0 gir1.2-poppler-0.18 libboost-atomic1.62-dev
libboost-atomic1.62.0 libboost-chrono1.62-dev libboost-chrono1.62.0
libboost-context1.62-dev libboost-context1.62.0
libboost-coroutine1.62-dev libboost-coroutine1.62.0
libboost-date-time1.62-dev libboost-date-time1.62.0
libboost-exception1.62-dev libboost-fiber1.62-dev
libboost-fiber1.62.0 libboost-filesystem1.62-dev
libboost-graph-parallel1.62-dev libboost-graph-parallel1.62.0
libboost-graph1.62-dev libboost-graph1.62.0 libboost-iostreams1.62-dev
libboost-locale1.62-dev libboost-locale1.62.0 libboost-log1.62-dev
libboost-log1.62.0 libboost-math1.62-dev libboost-math1.62.0
libboost-mpi-python1.62-dev libboost-mpi-python1.62.0
libboost-mpi1.62-dev libboost-mpi1.62.0
libboost-program-options1.62-dev libboost-program-options1.62.0
libboost-python1.62-dev libboost-python1.62.0
libboost-random1.62-dev libboost-regex1.62-dev
libboost-serialization1.62-dev libboost-serialization1.62.0
libboost-signals1.62-dev libboost-signals1.62.0
libboost-system1.62-dev libboost-test1.62-dev libboost-test1.62.0
libboost-thread1.62-dev libboost-timer1.62-dev libboost-timer1.62.0
libboost-type-erasure1.62-dev libboost-type-erasure1.62.0
libboost-wave1.62-dev libboost-wave1.62.0 libboost1.62-dev
libboost1.62-tools-dev libhwloc-dev libibverbs-dev libieee1284-3:i386
libnuma-dev libopenmpi-dev libpython3-dev libpython3.6-dev libwine
libwine:i386 linux-headers-4.13.0-21 linux-headers-4.13.0-21-generic
linux-image-4.13.0-21-generic linux-image-extra-4.13.0-21-generic
mc-data mpi-default-dev ocl-icd-libopencl1:i386 python-glade2
python3-dev python3.6-dev Thunderbird-locale-en wine32:i386 wine64
_Je n'ai ni le temps ni les connaissances nécessaires pour parcourir cette liste et trouver le package dont j'ai vraiment besoin et celui qui convient le mieux pour être supprimé.
J'ai également essayé de les marquer tous comme "manuels" dans l'espoir qu'après cela, _apt-get autoremove_ puisse déterminer ceux qui sont réellement orphelins et qu'il n'est pas souhaitable de supprimer. J'ai utilisé _aptitude keep-all_ et il gèle toujours. J'ai trouvé que c'est un bug supposé être corrigé mais apparemment ce n'est pas le cas.
Question: Quelle est l’approche la plus sûre pour supprimer les applications/bibliothèques indésirables dans Ubuntu qui n’implique pas la vérification de tous les paquets et de leurs dépendances un par un?
Les règles pour autoremoval sont en fait assez simples.
La réponse spécifique à votre question " est l'approche la plus sûre pour supprimer les applications/bibliothèques indésirables dans Ubuntu qui ne nécessitent pas la vérification de tous les paquets et de leurs dépendances un par un " est: Laissez Apt le faire c'est du boulot. Vous pouvez le faire quand vous comprenez mieux comment apt prend ses décisions. Pour la plupart des nouveaux utilisateurs, cela fait partie de la courbe d'apprentissage. Discutons donc de la logique d'Apt ...
Apt n'a aucune idée si vous utilisez un paquet ou non. Ce n'est pas psychique. Il ne connaît que les dépendances de chaque paquet et ce que vous lui dites. Pour qu'un colis soit éligible pour le retrait automatique (orphelin), il doit répondre à deux critères :
- Il doit être marqué avec apt comme
auto(au lieu demanual) - Aucun package
manualne dépend - directement ou indirectement - du package.
Il y a trois comportements compliquant qui déroutent les utilisateurs.
Apt se souvient des paquets que vous avez explicitement installés et marque ces paquets
manual. Toutes les autres dépendances sont marquéesauto.Le programme d’installation Ubuntu marque TOUS les paquets initiaux lors d’une nouvelle installation
manual. Cela empêche les nouveaux venus de retirer accidentellement d’énormes dalles de leur système.Les paquets de noyau fonctionnent légèrement différemment en raison d'un peu de script-fu Ubuntu.
C'est ça - deux règles et trois comportements spéciaux. Tout le reste n'est que vieille logique.
Examinons quelques exemples courants pour voir comment ces règles et ces comportements s’appliquent.
Exemple # 1 : Sudo apt install foo libfoo
Il est assez évident que tout ce qui s'appelle libfoo est probablement une dépendance de foo. Et apt le sait aussi. Cependant, nous avons explicitement dit qu'il était possible d'installer libfoo - il sera marqué manual et ne sera pas éligible pour un enlèvement automatique. Si au lieu de cela nous n'avions dit que Sudo apt install foo et laissé apt à calculer les dépendances, alors libfoo serait (correctement) marqué auto et deviendrait éligible pour un enlèvement automatique lorsque foo serait supprimé.
Exemple # 2 : Sudo apt remove ubuntu-desktop
Si vous construisez un système Ubuntu à partir de image minimale , ou si vous installez des piles LAMP ou de nouveaux environnements de bureau après l'installation initiale, des métapaquets tels que ubuntu-desktop are great - toute la pile en une seule commande. Mais regardez-le du point de vue d’apt: un seul paquetage manual et des dizaines (centaines) de auto dépendances. Le moment où vous désinstallez le méta-paquet en raison de l’essai d’une application différente ... eh bien, vous avez l’idée.
La solution consiste simplement à marquer vos applications principales de niveau supérieur comme manual:
Sudo apt install foo // Even if foo is already installed
Sudo apt-mark manual foo // Does the same thing
Sudo apt-mark auto libfoo // Makes libfoo eligible for autoremoval someday when foo gets removed
Sudo apt remove foo // Apt will remove foo *regardless* of apt-mark
Rappelez-vous que apt-marker indique simplement à apt quels packages vos applications de niveau supérieur sont inéligibles pour un enlèvement automatique - cela ne les protège PAS de la folie humaine.
Le moyen le plus simple de parcourir une liste d'autorisation automatique pour la plupart des gens consiste simplement à rechercher des packages d'applications clés de niveau supérieur - votre client de messagerie, votre navigateur Web, votre IDE, votre jeu préféré. Cherchez foo, ignorez libfoo. Quand on se glisse et qu'on le supprime, il suffit de le réinstaller - rappelez-vous que dire au système d'installer un paquet le marque manual. Cependant , votre cas d'utilisation est plus compliqué puisque vous compilez des logiciels et utilisez des packages -dev. Il n'y a pas de solution magique pour vous (désolé). Vous devez prendre le temps de savoir quels paquets sont importants pour vous ... tout comme le reste de nous.
Avertissement : Tout ceci s'applique aux paquets deb des référentiels Ubuntu. Si vous ajoutez beaucoup de paquets bizarres provenant d'un autre endroit, vous devrez faire plus de paquets. Rappelez-vous qu’apt n’a aucune connaissance en ce qui concerne pip, snap, flatpack, logiciel d’appimage, fichiers binaires ou scripts téléchargés, ni code compilé.