TL; DR o "Simplemente quema mi pi"
sudo apt-get remove --auto-remove --purge 'libx11-.*'
sudo apt-get autoremove --purge
(Repita apt-get autoremove --purgehasta que no queden huérfanos)
Explicación adicional
Si un paquete foo depende de otro paquete libfoo y usted elimina el paquete libfoo , el dependiente ( foo ) también se elimina. Debido a que Foo tiene una línea dependiente que especifica libfoo , se rompería si dejara foo si se eliminara libfoo. Lo contrario no es cierto: eliminar foo no elimina libfoo automáticamente. Otro paquete xfoo también puede depender de libfoo, por lo que apt no solo lo eliminará (aunque apt rastreará si se instaló solo como un efecto secundario de la instalación de foo y ofrezca eliminarlo automáticamente si así lo solicita, siempre y cuando nadie más dependa de él)
Los metapaquetes dependen de un conjunto de otros paquetes de la misma manera que foo dependía de libfoo , por lo que cuando se elimina un metapaquete , normalmente se elimina poco más. Por ejemplo, puede haber dos metapaquetes que dependen de xterm (lxsession y xfsession quizás), pero desinstalar uno o ambos no desinstalará xterm porque xterm no está roto sin lxsession o xfsession. Los metapaquetes están generalmente en la parte superior del árbol de dependencias, no en la parte inferior, y pocas cosas tienden a depender directamente de los metapaquetes. Los metapaquetes proporcionan principalmente una forma conveniente de instalar un conjunto sensible de paquetes a la vez, pero no son herramientas de desinstalación.
Por lo tanto, si desea quemar todo lo que depende de X11, tendrá que apuntar al conjunto base de bibliotecas libx11 de las que todas las aplicaciones x11 deben depender en última instancia:
sudo apt-get remove --dry-run --auto-remove --purge 'libx11-.*'
sudo apt-get autoremove --dry-run --purge
Esto (simulará) eliminará todo lo que finalmente depende de libx11 -. *, Y también eliminará todos los paquetes que se instalaron como una dependencia de un programa X11, incluso si no dependían directamente de X11 (CUPS y Ghostscript generalmente se instalan como efecto secundario de instalar un entorno de escritorio). El segundo comando eliminará a los huérfanos posteriores hasta que no quede ninguno. Elimine "--auto-remove" si desea realizar este paso más adelante o no hacerlo, o simplemente agregue los paquetes manualmente después de limpiar la GUI.
Elimine la opción --dry-run para realizar realmente la operación después de haber verificado que no eliminará los paquetes que no tenía la intención de eliminar).
Prefiero limpiar y purgar los efectos secundarios y agregarlos nuevamente según sea necesario. Además, seguí adelante y probé esto en mi propio pi, y se reinició en un servidor muy espartano pero funcional. :)
¿Por qué un remove instala algo?
La estrategia anterior resuelve el problema planteado, pero aún queda la curiosidad de por qué un remove operación resulta en paquetes que se instalan .
En el corazón de cada administrador de paquetes hay un solucionador de satisfacción de algún tipo. Cuando le dice a un administrador de paquetes que instale algunos paquetes, elimine algunos paquetes o actualice algunos paquetes, lo que realmente le pide que haga es resolver el siguiente estado deseado de instalación del software dado un conjunto de paquetes disponibles. Esta solución puede incluir instalar paquetes adicionales (dependencias), eliminar paquetes existentes (conflictos, interrupciones), degradar / actualizar paquetes específicos (nivel de compatibilidad) o una combinación de los mismos. Entonces, si bien es un poco contradictorio que el solucionador determine que algunos paquetes deben instalarse para que otros paquetes se eliminenTiene mucho sentido. Este es el desagradable problema de administración de dependencias que resuelven los administradores de paquetes.
Un ejemplo concreto: dado un conjunto de aplicaciones Java ya instaladas, todas dependen de un tiempo de ejecución compatible con Java que actualmente es openjdk-7-jre . Luego le pide al administrador de paquetes que resuelva la instalación de una nueva herramienta Java que declara un conflicto con openjdk-7-jre pero que funciona con oracle-7-jre (ambos paquetes generalmente proporcionan un tiempo de ejecución java-7 ). El solucionador propondrá la eliminación de openjdk-7-jre y la instalación de oracle-java-7-jrecomo la solución a su estado deseado de tener el nuevo paquete instalado sin romper los paquetes existentes.
En este específico caso, xterm es un paquete que ofrece una dependencia virtual llamado x-terminal-emulador ( xterm , lxterminal , y aterm todos proporcionan un -terminal-emulador x ), por lo que es probable que en la eliminación de lxterminal (como parte de eliminando lxde), el solucionador encontró un paquete instalado existente ( transcodificar como un posible ejemplo) que requería algún tipo de emulador x-terminal , por lo que el solucionador decidió instalar xterm (que requiere libutempter0 y xbitmaps, explicando los otros paquetes a instalar) para satisfacer la dependencia rota. Sin ver la base de datos del paquete, hipotetizaría que este es el escenario más probable.
Para descubrir los paquetes que actualmente dependen de xterm (o una alternativa), use el comando apt-cache rdepends (usando el interruptor --installed para limitar solo los paquetes instalados):
$ apt-cache --installed rdepends xterm
xterm
Reverse Depends:
|xorg
clusterssh
|xinit
|tk8.5
|tk8.4
|transcode
Dependencias que comienzan con el carácter de alternancia '|' significa que el paquete depende de xterm o de algo que proporciona (ese algo es x-terminal-emulator en este caso). El paquete clusterssh depende de xterm explícitamente y no permite una alternativa. Esta es la lista corta de los paquetes que están causando que se requiera xterm.
¿Qué hay de deborphan?
La funcionalidad de seguimiento de huérfanos se incorporó a apt-get a través de la funcionalidad 'autoremove' en 2010 (error de Debian 582791 ), lo que hace que deborphan sea en su mayoría redundante y esencialmente obsoleto. A diferencia de deborphan y otras soluciones como esta, apt-get rastrea directamente qué paquetes se instalaron explícitamente y qué paquetes se instalaron como efecto secundario o dependencia de un paquete instalado explícitamente. Por ejemplo, si un administrador instala foo, libtal se instala como un efecto secundario y apt-get autoremove voluntad , de hecho, eliminar libtal si no se especifica autoremove (o --auto-remove) al retirar foo.
El enfoque adoptado por deborphan es una colección de conjeturas. Por ejemplo, la suposición de que una biblioteca instalada que no tiene un dependiente debe ser huérfana: si libfoo está instalado, pero ni foo ni xfoo lo están, deborphan puede decidir que debe ser huérfano. Un modo de falla aquí es que las bibliotecas pueden instalarse específicamente para las herramientas que proporcionan (libxml2 para xmllint antes de volver a empaquetarlas en libxml2-utils) o simplemente estar disponibles para fines de desarrollo. Dichos paquetes no son huérfanos. Además, deborphan se enfoca en las bibliotecas, por lo que pierde una serie de huérfanos que no pertenecen a la biblioteca que pueden rastrear (paquetes obsoletos frente a paquetes huérfanos) .
muninpor alguna razón, pero pude volver a poner eso fácilmente después.