TL; DR ou "Basta queimar meu pi"
sudo apt-get remove --auto-remove --purge 'libx11-.*'
sudo apt-get autoremove --purge
(Repita apt-get autoremove --purgeaté que nenhum órfão permaneça)
Mais explicações
Se um pacote foo depende de outro pacote libfoo e você remove o pacote libfoo , o dependente ( foo ) também é removido. Como o Foo tem uma linha dependente que especifica o libfoo , seria quebrado para deixar o foo se o libfoo fosse removido. O inverso não é verdadeiro: remover foo não exclui o libfoo automaticamente. Outro pacote xfoo também pode depender do libfoo, portanto, o apt não o removerá (embora o apt rastreie se ele foi instalado apenas como um efeito colateral da instalação do foo e ofereça-o para removê-lo automaticamente, se você pedir, desde que outros ainda dependam dele)
Os meta-pacotes dependem de um conjunto de outros pacotes da mesma maneira que foo dependia do libfoo ; portanto, quando você remove um meta-pacote, pouco mais é normalmente removido. Por exemplo, pode haver dois meta-pacotes que dependem do xterm (lxsession e xfsession talvez), mas desinstalar um ou ambos não desinstalará o xterm porque o xterm não está quebrado sem o lxsession ou o xfsession. Meta-pacotes geralmente estão no topo da árvore de dependência, não na parte inferior, e poucas coisas tendem a depender diretamente dos meta-pacotes. Os meta-pacotes fornecem principalmente uma maneira conveniente de instalar um conjunto razoável de pacotes de uma só vez, mas não são ferramentas de desinstalação.
Portanto, se você deseja escalonar tudo o que depende do X11, precisará direcionar o conjunto básico de bibliotecas libx11 das quais todos os aplicativos x11 devem depender:
sudo apt-get remove --dry-run --auto-remove --purge 'libx11-.*'
sudo apt-get autoremove --dry-run --purge
Isso irá (simular) remover tudo o que depende da libx11 -. * E também removerá todos os pacotes que foram instalados como uma dependência de um programa X11, mesmo que eles não dependam diretamente do próprio X11 (o CUPS e o Ghostscript geralmente são instalados como efeito colateral da instalação de um ambiente de área de trabalho). O segundo comando removerá os órfãos subseqüentes até que nenhum permaneça. Remova "--auto-remove" se você quiser executar esta etapa mais tarde ou não fazer nada, ou apenas adicione os pacotes manualmente depois de limpar a GUI.
Remova a opção --dry-run para realmente executar a operação depois de verificar se ela não removerá os pacotes que você não pretendia remover.)
Prefiro limpar e purgar os efeitos colaterais e adicioná-los novamente, conforme necessário. Além disso, fui em frente e testei isso no meu próprio pi, e ele foi reiniciado em um servidor muito espartano, mas funcional. :)
Por que um remover instala algo?
A estratégia acima resolve o problema indicado, mas ainda há a curiosidade de por que um remove operação resulta em pacotes que estão sendo instalados .
No coração de todo gerenciador de pacotes está um solucionador de satisfação de algum tipo. Quando você instrui um gerente de pacotes a instalar alguns pacotes, remover alguns pacotes ou atualizar alguns pacotes, o que você realmente está pedindo é que resolva o próximo estado desejado de instalação do software, considerando um conjunto de pacotes disponíveis. Essa solução pode incluir a instalação de pacotes adicionais (dependências), a remoção de pacotes existentes (conflitos, quebras), a atualização / atualização de pacotes específicos (nível de compatibilidade) ou uma combinação deles. Portanto, embora seja um pouco contra-intuitivo que o solucionador determine que alguns pacotes precisam ser instalados para que outros sejam removidos, faz todo o sentido. Esse é o grave problema de gerenciamento de dependências que os gerenciadores de pacotes resolvem.
Um exemplo concreto: dado um conjunto de aplicativos Java já instalados, todos eles dependem de um tempo de execução compatível com java que atualmente é openjdk-7-jre . Em seguida, você solicita ao gerenciador de pacotes que resolva a instalação de uma nova ferramenta Java que declare um conflito com o openjdk-7-jre, mas trabalhe com o oracle-7-jre (ambos os pacotes geralmente fornecem um java-7-runtime ). O solucionador proporá uma remoção do openjdk-7-jre e uma instalação do oracle-java-7-jrecomo a solução para o estado desejado de instalação do novo pacote sem interromper os pacotes existentes.
Neste específico caso, o xterm é uma embalagem que proporciona uma dependência virtual chamados terminal X-emulador ( xterm , lxterminal , e aterm todos fornecer um terminal X-emulador ), por isso é provável que na remoção lxterminal (como uma parte de removendo o lxde), o solucionador encontrou um pacote instalado existente ( transcode como um possível exemplo) que exigia algum tipo de emulador de terminal x ; portanto, o solucionador optou por instalar o xterm (que requer libutempter0 e xbitmaps, explicando os outros pacotes a serem instalados) para satisfazer a dependência quebrada. Sem ver o banco de dados do pacote, eu hipotetizaria que esse é o cenário mais provável.
Para descobrir os pacotes que atualmente dependem do xterm (ou de uma alternativa), use o comando apt-cache rdepends (usando a opção --installed para limitar apenas os pacotes instalados):
$ apt-cache --installed rdepends xterm
xterm
Reverse Depends:
|xorg
clusterssh
|xinit
|tk8.5
|tk8.4
|transcode
Dependências que começam com o caractere de alternância '|' significa que o pacote depende do xterm ou de algo que ele fornece (que algo é emulador de terminal x nesse caso). O pacote clusterssh depende explicitamente do xterm e não permite uma alternativa. Esta é a lista curta dos pacotes que estão causando o xterm ser necessário.
E o deborphan?
A funcionalidade de rastreamento de órfãos foi incorporada ao apt-get através da funcionalidade 'autoremove' em 2010 (Debian bug 582791 ), tornando o deborphan principalmente redundante e essencialmente obsoleto. Diferentemente do deborphan e de outras soluções, o apt-get rastreia diretamente quais pacotes foram explicitamente instalados e quais foram instalados como efeito colateral ou dependência de um pacote explicitamente instalado. Por exemplo, se um administrador instala foo, libfoo é instalado como um efeito colateral e apt-get autoremove vontade , de fato, remover libfoo se autoremove (ou --auto-remove) é especificado quando remover foo.
A abordagem adotada pelo deborphan é uma coleção de suposições. Por exemplo, a suposição de que uma biblioteca instalada que não possui um dependente deve ser órfã: se o libfoo estiver instalado, mas nem foo nem xfoo , o deborphan pode decidir que deve ser órfão. Um modo de falha aqui é que as bibliotecas podem ser instaladas especificamente para as ferramentas que eles fornecem (libxml2 para xmllint antes de ser reembalado no libxml2-utils) ou simplesmente disponíveis para fins de desenvolvimento. Esses pacotes não são órfãos. Além disso, o deborphan se concentra nas bibliotecas, por isso perde um número de órfãos que não pertencem à biblioteca, que seguem trilhas (pacotes obsoletos vs. pacotes órfãos) .
muninpor algum motivo, mas eu pude recuperá-lo com bastante facilidade depois.