TL; DR o "Basta bruciare il mio pi"
sudo apt-get remove --auto-remove --purge 'libx11-.*'
sudo apt-get autoremove --purge
(Ripeti apt-get autoremove --purgefinché non rimangono orfani)
Ulteriori spiegazioni
Se un pacchetto foo dipende da un altro pacchetto libfoo e si rimuove il pacchetto libfoo , viene rimosso anche il dipendente ( foo ). Poiché Foo ha una dipende linea specificando libfoo , sarebbe rotto per lasciare foo se libfoo sono stati rimossi. Il contrario non è vero: la rimozione di foo non cancella automaticamente libfoo . Un altro pacchetto xfoo può anche dipendere da libfoo, quindi apt non lo rimuoverà (anche se apt monitorerà se è stato installato solo come effetto collaterale dell'installazione di foo e offriti di rimuoverlo automaticamente se lo chiedi, a condizione che nessun altro dipenda ancora da esso)
I meta-pacchetti dipendono da una serie di altri pacchetti nello stesso modo in cui il foo dipendeva da libfoo , quindi quando rimuovi un meta-pacchetto, poco altro viene in genere rimosso. Ad esempio, potrebbero esserci due meta-pacchetti che dipendono da xterm (forse lxsession e xfsession), ma disinstallare uno o entrambi non disinstallerà xterm perché xterm non è rotto senza lxsession o xfsession. I meta-pacchetti sono generalmente nella parte superiore dell'albero delle dipendenze, non nella parte inferiore, e poche cose tendono a dipendere direttamente dai meta-pacchetti. I meta-pacchetti forniscono principalmente un modo conveniente per installare contemporaneamente una serie ragionevole di pacchetti, ma non sono strumenti di disinstallazione.
Quindi, se vuoi bruciare tutto ciò che dipende da X11, dovrai scegliere come target il set di base delle librerie libx11 da cui tutte le app x11 devono infine dipendere:
sudo apt-get remove --dry-run --auto-remove --purge 'libx11-.*'
sudo apt-get autoremove --dry-run --purge
Questo (simulerà) rimuoverà tutto ciò che alla fine dipende da libx11 -. * E rimuoverà anche tutti i pacchetti installati come dipendenza di un programma X11 anche se non dipendevano direttamente da X11 stesso (CUPS e Ghostscript sono generalmente installati come effetto collaterale dell'installazione di un ambiente desktop). Il secondo comando rimuoverà gli orfani successivi fino a quando nessuno rimarrà. Rimuovere "--auto-remove" se si desidera eseguire questo passaggio in un secondo momento o non farlo affatto, o semplicemente aggiungere nuovamente i pacchetti manualmente dopo aver pulito la GUI.
Rimuovere l' opzione --dry-run per eseguire effettivamente l'operazione dopo aver verificato che non rimuoverà i pacchetti che non si intendeva rimuovere.)
Preferisco pulire ed eliminare gli effetti collaterali e aggiungerli nuovamente se necessario. Inoltre, sono andato avanti e l'ho provato sul mio pi, e si è riavviato su un server molto spartano ma funzionale. :)
Perché una rimozione installa qualcosa?
La strategia di cui sopra risolve il problema dichiarato, ma c'è ancora la curiosità del motivo per cui un'operazione di rimozione comporta l' installazione di pacchetti .
Al centro di ogni gestore di pacchetti c'è un risolutore di soddisfazioni di qualche tipo. Quando si dice a un gestore di pacchetti di installare alcuni pacchetti, rimuovere alcuni pacchetti o aggiornarne alcuni, ciò che si sta realmente chiedendo di fare è risolvere il successivo stato desiderato di installazione del software, dato un set disponibile di pacchetti. Questa soluzione può includere l'installazione di pacchetti aggiuntivi (dipendenze), la rimozione di pacchetti esistenti (conflitti, interruzioni), il downgrade / l'aggiornamento di pacchetti specifici (livello di compatibilità) o una loro combinazione. Quindi, sebbene sia un po 'controintuitivo, il risolutore determina che alcuni pacchetti devono essere installati per poter rimuovere altri pacchetti, ha perfettamente senso. Questo è il brutto problema di gestione delle dipendenze che i gestori di pacchetti risolvono.
Un esempio concreto: dato un set di applicazioni Java già installate, dipendono tutte da un runtime compatibile con Java che attualmente risulta essere openjdk-7-jre . Quindi si chiede al gestore pacchetti di risolvere l'installazione di un nuovo strumento Java che dichiara un conflitto con openjdk-7-jre ma funziona con oracle-7-jre (entrambi i pacchetti genericamente forniscono un java-7-runtime ). Il solutore proporrà una rimozione di openjdk-7-jre e un'installazione di oracle-java-7-jrecome soluzione per lo stato desiderato di installazione del nuovo pacchetto senza interrompere i pacchetti esistenti.
In questo caso specifico , xterm è un pacchetto che fornisce una dipendenza virtuale chiamata x-terminal-emulator ( xterm , lxterminal e aterm forniscono tutti un x-terminal-emulator ), quindi è probabile che rimuovendo lxterminal (come parte di rimuovendo lxde), il solutore ha trovato un pacchetto installato esistente ( transcodifica come possibile esempio) che richiedeva un qualche tipo di emulatore x-terminal , quindi il solutore ha scelto di installare xterm (che richiede libutempter0 e xbitmaps, spiegando gli altri pacchetti da installare) per soddisfare la dipendenza altrimenti rotta. Senza vedere il database dei pacchetti, ipotizzerei che questo sia lo scenario più probabile.
Per scoprire i pacchetti che dipendono attualmente da xterm (o da un altro), usare il comando apt-cache rdepends (usando l' opzione --installed per limitare solo ai pacchetti installati):
$ apt-cache --installed rdepends xterm
xterm
Reverse Depends:
|xorg
clusterssh
|xinit
|tk8.5
|tk8.4
|transcode
Dipendenze che iniziano con il carattere di alternanza '|' significa che il pacchetto dipende da xterm o da qualcosa che fornisce (che in questo caso qualcosa è x-terminal-emulator ). Il pacchetto clusterssh dipende esplicitamente da xterm e non consente un'alternativa. Questa è la breve lista dei pacchetti che stanno causando la richiesta di xterm.
Che dire di deborphan?
La funzionalità di tracciamento degli orfani è stata incorporata in apt-get tramite la funzionalità "autoremove" nel 2010 (bug Debian 582791 ) rendendo il deborphan per lo più ridondante ed essenzialmente obsoleto. A differenza di deborphan e di altre soluzioni simili, apt-get traccia direttamente quali pacchetti sono stati installati esplicitamente e quali pacchetti sono stati installati come effetto collaterale o dipendenza di un pacchetto installato esplicitamente. Ad esempio, se un amministratore installa foo, libfoo è installato come effetto collaterale e apt-get autoremove volontà , infatti, rimuovere libfoo se non viene specificato autoremove (o --auto-rimozione) durante la rimozione foo.
L'approccio adottato da deborphan è una raccolta di ipotesi. Ad esempio, supponendo che una libreria installata che non abbia un dipendente debba essere un orfano: se è installato libfoo , ma non lo sono né foo né xfoo , deborphan può decidere che deve essere un orfano. Una modalità di errore qui è che le librerie potrebbero essere installate specificamente per gli strumenti che forniscono (libxml2 per xmllint prima di essere riconfezionate in libxml2-utils) o semplicemente disponibili per scopi di sviluppo. Tali pacchetti non sono orfani. Inoltre, deborphan si concentra sulle librerie, quindi manca un numero di orfani non di libreria che apt track (pacchetti obsoleti vs. pacchetti orfani) .
muninper qualche motivo, ma ho potuto rimetterlo abbastanza facilmente in seguito.