TL; DR lub „Just scorch my pi”
sudo apt-get remove --auto-remove --purge 'libx11-.*'
sudo apt-get autoremove --purge
(Powtarzaj, apt-get autoremove --purgeaż nie pozostanie sierota)
Dalsze wyjaśnienia
Jeśli pakiet foo zależy od innego pakietu libfoo, a ty usuniesz pakiet libfoo , to zależne ( foo ) również zostanie usunięte. Ponieważ Foo ma linię zależną określającą libfoo , opuszczenie foo byłoby zerwane, gdyby libfoo zostało usunięte. Odwrotna sytuacja nie jest prawdą: usunięcie foo nie usuwa automatycznie libfoo . Inny pakiet xfoo może również zależeć od libfoo, więc apt nie tylko go usunie (chociaż apt będzie śledził, czy został zainstalowany tylko jako efekt uboczny instalacji foo i zaoferuj automatyczne usunięcie, jeśli o to poprosisz, o ile nikt inny nie będzie od tego zależał)
Meta-pakiety zależą od zestawu innych pakietów w bardzo podobny sposób, w jaki foo zależało od libfoo , więc kiedy usuwasz meta-pakiet, niewiele innych jest zazwyczaj usuwanych. Na przykład mogą istnieć dwa meta-pakiety zależne od xterm (być może lxsession i xfsession), ale odinstalowanie jednego lub obu nie spowoduje odinstalowania xterm, ponieważ xterm nie jest uszkodzony bez lxsession lub xfsession. Meta-paczki są zazwyczaj na górze drzewa zależności, a nie na dole, a niewiele rzeczy zwykle zależy bezpośrednio od meta-pakietów. Meta-pakiety przede wszystkim zapewniają wygodny sposób instalacji rozsądnego zestawu pakietów jednocześnie, ale nie są to narzędzia do odinstalowywania.
Tak więc, jeśli chcesz przypalić wszystko , co zależy od X11, musisz celować w podstawowy zestaw bibliotek libx11, od którego ostatecznie muszą zależeć wszystkie aplikacje x11 :
sudo apt-get remove --dry-run --auto-remove --purge 'libx11-.*'
sudo apt-get autoremove --dry-run --purge
Spowoduje to (symulację) usunięcie wszystkiego, co ostatecznie zależy od libx11 -. *, A także usunie wszystkie pakiety, które zostały zainstalowane jako zależność programu X11, nawet jeśli nie były bezpośrednio zależne od samego X11 (zwykle instalowane są CUPS i Ghostscript jako efekt uboczny instalacji środowiska pulpitu). Drugie polecenie usunie kolejne sieroty, dopóki nie pozostaną żadne. Usuń „--auto-remove”, jeśli chcesz zrobić ten krok później lub w ogóle go nie robić, lub po prostu dodaj pakiety ręcznie po oczyszczeniu GUI.
Usuń opcję --dry-run , aby faktycznie wykonać operację po sprawdzeniu, że nie usunie ona pakietów, których nie zamierzałeś usunąć.)
Wolę oczyścić i oczyścić skutki uboczne i dodawać je w razie potrzeby. Ponadto poszedłem do przodu i przetestowałem to na mojej własnej pi, i zrestartowałem się do bardzo spartańskiego, ale funkcjonalnego serwera. :)
Dlaczego usunięcie coś instaluje ?
Powyższa strategia rozwiązuje zadany problem, ale wciąż istnieje ciekawość, dlaczego operacja usunięcia powoduje zainstalowanie pakietów .
Sercem każdego menedżera pakietów jest pewnego rodzaju solver satysfakcji . Gdy powiesz menedżerowi pakietów, aby zainstalował niektóre pakiety, usunął niektóre pakiety lub zaktualizował niektóre, naprawdę tak naprawdę prosisz o rozwiązanie kolejnego wymaganego stanu instalacji oprogramowania, biorąc pod uwagę dostępny zestaw pakietów. To rozwiązanie może obejmować instalowanie dodatkowych pakietów (zależności), usuwanie istniejących pakietów (konflikty, przerwy), obniżanie / uaktualnianie określonych pakietów (poziom zgodności) lub ich kombinację. Tak więc, choć jest to nieco sprzeczne z intuicją, solver określa, że niektóre pakiety muszą zostać zainstalowane , aby inne pakiety mogły zostać usunięte, to ma sens. Jest to paskudny problem zarządzania zależnościami, który rozwiązują menedżerowie pakietów.
Konkretny przykład: Biorąc pod uwagę zestaw zainstalowanych aplikacji Java, wszystkie zależą od środowiska wykonawczego kompatybilnego z Javą, którym obecnie jest openjdk-7-jre . Następnie poprosić menedżera pakietów rozwiązania dla instalacji nowego narzędzia Java, który deklaruje konflikt z openjdk-7-jre ale pracuje z oracle-7-jre (oba pakiety rodzajowo dostarczyć do java-7-runtime ). Solver zaproponuje usunięcie z openjdk-7-jre i instalacji z Oracle Java-7-jrejako rozwiązanie dla pożądanego stanu posiadania nowego pakietu bez rozbijania istniejących pakietów.
W tym konkretnym przypadku, xterma to pakiet zawiera wirtualny zależność zwane x-końcowych Emulator ( xterma , lxterminal i aterm wszystko zapewnić o x-terminala emulator ), a więc jest prawdopodobne, że w usuwaniu lxterminal (w ramach usuwając lxde), solver znalazł istniejący zainstalowany pakiet ( transkrypt jako możliwy przykład), który wymagał pewnego rodzaju emulatora terminala x , więc solver zdecydował się zainstalować xterm (który wymaga libutempter0 i xbitmaps, wyjaśniając inne pakiety do zainstalowania), aby zaspokoić w przeciwnym razie zależność. Nie widząc bazy danych pakietów, postawiłbym hipotezę, że jest to najbardziej prawdopodobny scenariusz.
Aby odkryć pakiety, które są obecnie zależne od xterm (lub alternatywy), użyj polecenia apt-cache rdepends (używając przełącznika --installed, aby ograniczyć tylko do zainstalowanych pakietów):
$ apt-cache --installed rdepends xterm
xterm
Reverse Depends:
|xorg
clusterssh
|xinit
|tk8.5
|tk8.4
|transcode
Zależności rozpoczynające się od znaku naprzemiennego „|” oznacza, że pakiet zależy od xterm lub czegoś, co zapewnia ( w tym przypadku coś jest emulatorem terminala x ). Clusterssh pakiet zależy xterm jawnie , a nie pozwala na alternatywę. Oto krótka lista pakietów, które powodują, że Xterm jest wymagany.
A co z deborphanem?
Funkcja śledzenia sierot została włączona do apt-get za pośrednictwem funkcji „autorove” w 2010 r. (Błąd Debiana 582791 ), co powoduje, że deborphan jest w większości zbędny i zasadniczo przestarzały. W przeciwieństwie do deborphan i innych podobnych rozwiązań apt-get bezpośrednio śledzi, które pakiety zostały jawnie zainstalowane, a które zostały zainstalowane jako efekt uboczny lub zależność od jawnie zainstalowanego pakietu. Na przykład, jeżeli administrator instaluje foo, libfoo jest instalowany jako efekt uboczny i apt-get autoremove woli , w rzeczywistości, usunąć libfoo jeśli autoremove (lub --auto-remove) jest określona przy usuwaniu foo.
Podejście przyjęte przez deborphan jest zbiorem domysłów. Na przykład przypuszczenie, że zainstalowana biblioteka, która nie jest zależna, musi być sierotą: Jeśli zainstalowano libfoo , ale nie są to ani foo, ani xfoo , deborphan może zdecydować, że musi być sierotą. Jednym z trybów awaryjnych jest to, że biblioteki mogą być instalowane specjalnie dla dostarczanych przez nich narzędzi (libxml2 dla xmllint przed ponownym spakowaniem do libxml2-utils) lub po prostu dostępne do celów programistycznych. Takie pakiety nie są sierotami. Ponadto deborphan koncentruje się na bibliotekach, więc pomija pewną liczbę nie-bibliotekowych sierot, które nadają się do śledzenia (pakiety przestarzałe vs. pakiety osierocone) .
muninjakiegoś powodu również to usunąłem, ale później mogłem to łatwo odłożyć.