TL; DR ou "Juste brûler mon pi"
sudo apt-get remove --auto-remove --purge 'libx11-.*'
sudo apt-get autoremove --purge
(Répétez apt-get autoremove --purgejusqu'à ce qu'il ne reste plus d'orphelin)
Plus d'explications
Si un paquet foo dépend d'un autre paquet libfoo et que vous supprimez le paquet libfoo , la personne à charge ( foo ) est également supprimée. Parce que Foo a une ligne de dépendance spécifiant libfoo , il serait cassé de laisser foo si libfoo était supprimé. L'inverse n'est pas vrai: supprimer foo ne supprime pas automatiquement libfoo . Un autre paquet xfoo peut aussi dépendre de libfoo, donc apt ne supprimera pas juste (bien que qu'apt suivre si elle a été installée que comme un effet secondaire de l' installation foo et offre de le supprimer automatiquement si vous le demandez, tant qu'aucun autre n'en dépend toujours)
Les méta-paquets dépendent d'un ensemble d'autres paquets de la même manière que foo dépend de libfoo . Ainsi, lorsque vous supprimez un méta-paquet, il ne reste généralement rien d'autre. Par exemple, il peut y avoir deux méta-packages qui dépendent de xterm (lxsession et xfsession peut-être), mais la désinstallation de l'un ou des deux ne désinstallera pas xterm car xterm n'est pas en panne sans lxsession ou xfsession. Les méta-packages sont généralement au sommet de l'arbre de dépendance, pas au bas, et peu de choses ont tendance à dépendre directement des méta-packages. Les méta-packages constituent principalement un moyen pratique d’installer simultanément un ensemble raisonnable de packages, mais ils ne sont pas des outils de désinstallation.
Donc, si vous voulez brûler tout ce qui dépend de X11, vous devez cibler le jeu de base de bibliothèques libx11 sur lequel toutes les applications x11 doivent dépendre:
sudo apt-get remove --dry-run --auto-remove --purge 'libx11-.*'
sudo apt-get autoremove --dry-run --purge
(Simulera) supprimera tout ce qui dépend finalement de libx11 -. *, Ainsi que tous les paquetages installés en tant que dépendance d’un programme X11, même s’ils ne dépendent pas directement de X11 lui-même (CUPS et Ghostscript sont généralement installés comme effet secondaire de l’installation d’un environnement de bureau). La deuxième commande supprimera les orphelins suivants jusqu'à ce qu'il n'en reste plus. Supprimez "--auto-remove" si vous souhaitez effectuer cette étape ultérieurement ou si vous ne le faites pas du tout, ou rajoutez simplement les packages manuellement après le nettoyage de l'interface graphique.
Supprimez l' option --dry-run pour effectuer réellement l'opération après avoir vérifié qu'elle ne supprime pas les packages que vous n'aviez pas l'intention de supprimer.)
Je préfère nettoyer et purger les effets secondaires et les rajouter au besoin. De plus, je suis allé de l’avant et l’ai testé sur mon propre pi, puis il a redémarré sur un serveur très spartiate mais fonctionnel. :)
Pourquoi une suppression installe- t-elle quelque chose?
La stratégie ci-dessus résout le problème énoncé, mais il reste à savoir pourquoi une opération de suppression entraîne l' installation de packages .
Au cœur de chaque gestionnaire de paquets se trouve un résolveur de la satisfiabilité . Lorsque vous demandez à un gestionnaire de packages d' installer certains packages, de supprimer certains packages ou de mettre à niveau certains packages, vous lui demandez réellement de résoudre le prochain état souhaité de l'installation du logiciel en fonction d'un ensemble de packages disponible. Cette solution peut inclure l'installation de packages supplémentaires (dépendances), la suppression de packages existants (conflits, ruptures), la mise à niveau / la mise à niveau de packages spécifiques (niveau de compatibilité) ou une combinaison de ces éléments. Donc, même s’il est un peu contre-intuitif que le solutionneur détermine que certains packages doivent être installés pour que d’autres soient supprimés, c'est parfaitement logique. C'est le vilain problème de gestion des dépendances que les gestionnaires de paquets résolvent.
Un exemple concret: étant donné un ensemble d’applications Java déjà installées, elles dépendent toutes d’une exécution compatible avec Java qui se trouve être actuellement openjdk-7-jre . Vous demandez ensuite au gestionnaire de paquets de résoudre pour l'installation d'un nouvel outil Java qui déclare un conflit avec openjdk-7-jre mais qui fonctionne avec oracle-7-jre (les deux paquets fournissent généralement un runtime java-7 ). Le solveur proposera un retrait de openjdk-7-jre et une installation de oracle-java-7-jreen tant que solution à votre état souhaité, à savoir installer le nouveau package sans rompre les packages existants.
Dans ce cas particulier , xterm est un paquet qui fournit une dépendance virtuelle appelée x-terminal-emulator ( xterm , lxterminal et aterm fournit tous un émulateur x-terminal ), il est donc probable que la suppression de lxterminal (dans le cadre de en supprimant lxde), le solveur a trouvé un paquet existant ( transcode par exemple) nécessitant une sorte d’ émulateur x-terminal , il a donc choisi d’installer xterm (qui nécessite libutempter0 et xbitmaps)., expliquant les autres paquets à installer) pour satisfaire la dépendance autrement cassée. Sans voir la base de données de paquets, je suppose que c'est le scénario le plus probable.
Pour découvrir les paquets qui dépendent actuellement de xterm (ou un autre), utilisez la commande apt-cache rdepends (en utilisant le commutateur --installed pour limiter les paquets installés):
$ apt-cache --installed rdepends xterm
xterm
Reverse Depends:
|xorg
clusterssh
|xinit
|tk8.5
|tk8.4
|transcode
Dépendances commençant par le caractère d'alternance '|' signifie que le paquet dépend de xterm ou de quelque chose qu'il fournit (que quelque chose est x-terminal-emulator dans ce cas). Le paquetage clusterssh dépend de xterm de manière explicite , et ne permet aucune alternative. Ceci est la courte liste des paquets qui font que xterm est requis.
Qu'en est-il de deborphan?
La fonctionnalité de suivi des orphelins a été intégrée à apt-get via la fonctionnalité 'autoremove' en 2010 (bogue Debian 582791 ), rendant deborphan la plupart du temps redondant et essentiellement obsolète. Contrairement à deborphan et à d’autres solutions similaires, apt-get suit directement quels paquets ont été explicitement installés et quels paquets ont été installés en tant qu’effet secondaire ou dépendance d’un paquet explicitement installé. Par exemple, si un administrateur installe foo, libfoo est installé comme un effet secondaire et apt-get autoremove volonté , en effet, supprimer libfoo si autoremove (ou --auto-remove) est spécifié lors de la suppression foo.
L'approche adoptée par deborphan est une collection de suppositions. Par exemple, supposons qu'une bibliothèque installée sans personne dépendante soit un orphelin: si libfoo est installé, mais ni foo ni xfoo ne le sont, deborphan peut décider que ce doit être un orphelin. Un des modes d'échec est que des bibliothèques peuvent être spécifiquement installées pour les outils qu'elles fournissent (libxml2 pour xmllint avant d'être reconditionnées dans libxml2-utils) ou simplement disponibles à des fins de développement. Ces forfaits ne sont pas orphelins. En outre, deborphan se concentre sur les bibliothèques, de sorte qu’il manque un certain nombre d’ orphelins autres que des bibliothèques qui sont suivis par apt (packages obsolètes ou packages orphelins) .
muninpour une raison quelconque, mais je pouvais le remettre assez facilement par la suite.