TL; DR або "Просто спалюй мою пі"
sudo apt-get remove --auto-remove --purge 'libx11-.*'
sudo apt-get autoremove --purge
(Повторюйте, apt-get autoremove --purgeпоки не залишиться сиріт)
Подальше пояснення
Якщо пакет foo залежить від іншого пакету libfoo, а ви видалите пакет libfoo , залежний ( foo ) також буде видалений. Тому що Foo має залежить лінію , що вказує libfoo , вона буде зламана , щоб залишити Foo якщо libfoo були видалені. Зворотний бік не відповідає дійсності: видалення foo не видаляє libfoo автоматично. Інший пакет xfoo також може залежати від libfoo, тому apt не буде просто його видаляти (хоча apt буде відслідковувати, чи був він встановлений лише як побічний ефект установки foo і запропонуйте його автоматично видалити, якщо ви попросите, доки інші люди все ще не залежать від нього)
Мета-пакети залежать від набору інших пакетів приблизно так само, як і foo залежав від libfoo , тому коли ви видаляєте мета-пакет, мало що інше видаляється. Наприклад, можуть бути два метапакети, які залежать від xterm (можливо, lxsession та xfsession), але видалення одного або обох не видалить xterm, оскільки xterm не порушено без lxsession чи xfsession. Метапакети, як правило, вгорі дерева залежностей, а не внизу, і деякі речі, як правило, безпосередньо залежать від метапакетів. Метапакети в першу чергу забезпечують зручний спосіб встановлення розумного набору пакетів відразу, але вони не видаляють інструменти.
Отже, якщо ви хочете розглянути все, що залежить від X11, вам потрібно буде орієнтуватися на базовий набір бібліотек libx11, від якого в кінцевому підсумку повинні залежати всі додатки x11 :
sudo apt-get remove --dry-run --auto-remove --purge 'libx11-.*'
sudo apt-get autoremove --dry-run --purge
Це (імітувати) видалить усе, що в кінцевому підсумку залежить від libx11 -. *, А також видалить усі пакунки, які були встановлені як залежність програми X11, навіть якщо вони безпосередньо не залежали від самого X11 (зазвичай встановлені CUPS та Ghostscript як побічний ефект установки робочого середовища). Друга команда видалить наступних сиріт, поки жодного не залишиться. Видаліть "--auto-remove", якщо ви хочете зробити цей крок пізніше або зовсім не зробити цього, або просто додайте назад пакети вручну після очищення графічного інтерфейсу.
Видаліть опцію --dry-run, щоб фактично виконати операцію після того, як ви перевірили, що вона не видалить пакунки, які ви не збиралися видаляти.)
Я вважаю за краще очищати та очищати побічні ефекти, а також додавати їх за потребою. Крім того, я пішов і випробував це на своєму пі, і він перезавантажився на дуже спартанському, але функціональному сервері. :)
Чому видалення щось встановлює ?
Вищеописана стратегія вирішує заявлену проблему, але все ще існує цікавість, чому операція видалення призводить до встановлення пакетів .
У серці кожного менеджера пакетів є здійсненність вирішувач який - то. Коли ви говорите менеджеру пакетів про встановлення деяких пакетів, видалення деяких пакетів або оновлення деяких пакетів, те, що ви насправді просите це зробити, це вирішити наступний бажаний стан встановлення програмного забезпечення з урахуванням наявного набору пакетів. Це рішення може включати встановлення додаткових пакетів (залежності), видалення існуючих пакетів (конфлікти, розриви), пониження / оновлення конкретних пакетів (рівень сумісності) або їх комбінацію. Таким чином, хоча вирішувач визначає, що деякі пакунки потрібно встановити для того, щоб інші пакети були видалені., це має ідеальний сенс. Це неприємна проблема управління залежністю, яку вирішують менеджери пакунків.
Конкретний приклад: Враховуючи набір уже встановлених програм Java, всі вони залежать від сумісного з Java -режиму виконання, який на даний момент буває openjdk-7-jre . Потім ви попросите менеджера пакунків вирішити для встановлення нового інструменту Java, який оголошує конфлікт з openjdk-7-jre, але працює з oracle-7-jre (обидва пакети загалом забезпечують виконання Java-7 ). Солвер запропонує видалення з OpenJDK-7-JRE і встановити на Oracle-Java-7-JREяк рішення бажаного стану встановлення нового пакета, не порушуючи існуючі пакунки.
У цьому конкретному випадку, Xterm є пакет , який надає віртуальну залежність званих х-термінал-емулятор ( Xterm , lxterminal і Aterm все забезпечують в й-термінальному-емуляторі ), так що цілком ймовірно , що при видаленні lxterminal (як частина видалення LXDE), вирішувач знайшов існуючий встановлений пакет ( перекодувати в якості можливого прикладу) , які вимагають який - то вид х-термінал-емулятор , тому вирішувач вибрав для установки Xterm (який вимагає libutempter0 і xbitmaps, пояснюючи інші пакунки для встановлення), щоб задовольнити інакше розбиту залежність. Не бачачи бази даних пакетів, я б припустив, що це найбільш вірогідний сценарій.
Щоб виявити пакети, які в даний час залежать від xterm (або альтернативного), використовуйте команду apt-cache rdepends (використовуючи перемикач --installed для обмеження лише встановлених пакетів):
$ apt-cache --installed rdepends xterm
xterm
Reverse Depends:
|xorg
clusterssh
|xinit
|tk8.5
|tk8.4
|transcode
Залежності, що починаються з символу чергування '|' означає, що пакет залежить від xterm або чогось, що він надає (що щось є x-terminal-emulator у цьому випадку). Пакет clusterssh прямо залежить від xterm і не дозволяє використовувати альтернативу. Це короткий список пакетів, які викликають необхідність xterm.
Що з деборфаном?
Функціональність відстеження сиріт була включена в apt-get через функцію "autoremove" в 2010 році (Debian bug 582791 ), що робить деборфаном в основному зайвим і по суті застарілим. На відміну від deborphan та інших подібних рішень, apt-get безпосередньо відстежує, які пакунки були явно встановлені та які пакунки були встановлені як побічний ефект або залежність від явно встановленого пакету. Наприклад, якщо адміністратор встановлює Foo, libfoo встановлюється в якості побічного ефекту і APT-отримати autoremove буде , насправді, видалити libfoo якщо autoremove (або --auto-видалити) задається при видаленні Foo.
Підхід деборфану - це набір здогадок. Наприклад, здогадка про те, що встановлена бібліотека, яка не має залежних, повинна бути сиротою: якщо libfoo встановлений, але ні foo, ні xfoo , deborphan може вирішити, що він повинен бути сиротою. Одним з режимів відмови є те, що бібліотеки можуть бути спеціально встановлені для наданих ними інструментів (libxml2 для xmllint до того, як вона була перепакована в libxml2-utils) або просто доступні для цілей розробки. Такі пакети не є сиротами. Крім того, deborphan зосереджується на бібліотеках, тому він не вистачає ряду небібліотечних сиріт, які підходять доріжок (застарілі пакети проти осиротілих пакетів) .
muninз якоїсь причини, але я міг поставити цю спинку досить легко після цього.