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 , но работает с оракулом-7-JRE (оба пакета в общем предоставляет в Java-7-среде выполнения ). Солвер предложит удаление из OpenJDK-7-JRE и установить на Oracle-Java-7-JREкак решение желаемого состояния установки нового пакета, не нарушая существующие пакеты.
В этом конкретном случае, Xterm это пакет , который предоставляет виртуальную зависимость называемых х-терминал-эмулятор ( Xterm , lxterminal и Aterm все обеспечить в й-терминальном-эмуляторе ), поэтому вполне вероятно , что при удалении lxterminal (в составе удаление LXDE), решатель нашел существующий установленный пакет ( перекодировать в качестве возможного примера) , которые требуют какой - то вид х-терминал-эмулятор , поэтому решатель выбрал для установки Xterm (который требует libutempter0 и xbitmaps, объясняя другие пакеты для установки), чтобы удовлетворить в противном случае нарушенную зависимость. Не видя базы данных пакетов, я бы предположил, что это наиболее вероятный сценарий.
Для того, чтобы открыть пакеты, которые в настоящее время в зависимости от XTerm (или альтернативный), используйте apt-кэш RDEPENDS команды (используя --installed переключателя ограничивать установленные пакеты только):
$ apt-cache --installed rdepends xterm
xterm
Reverse Depends:
|xorg
clusterssh
|xinit
|tk8.5
|tk8.4
|transcode
Зависимости, которые начинаются с символа чередования '|' означает, что пакет зависит от xterm или чего-то, что он предоставляет (что-то в данном случае является x-терминал-эмулятором ). Пакет clusterssh явно зависит от xterm и не допускает альтернативы. Это краткий список пакетов, вызывающих необходимость использования xterm.
Что насчет деборфана?
Функциональность отслеживания сирот была включена в apt-get с помощью функции «autoremove» в 2010 году (ошибка Debian 582791 ), что делает деборфан в основном избыточным и, по сути, устаревшим. В отличие от deborphan и других подобных решений, apt-get напрямую отслеживает, какие пакеты были установлены явно, а какие были установлены как побочный эффект или зависимость явно установленного пакета. Например, если администратор устанавливает Foo, libfoo устанавливается в качестве побочного эффекта и APT-получить autoremove будет , на самом деле, удалить libfoo если autoremove (или --auto-удалить) задается при удалении Foo.
Подход, принятый deborphan, представляет собой сборник догадок. Например, предположение о том, что установленная библиотека, не имеющая зависимого элемента, должна быть сиротой: если libfoo установлена, но не установлены ни foo, ни xfoo , deborphan может решить, что она должна быть сиротой. Один из режимов сбоя заключается в том, что библиотеки могут быть специально установлены для предоставляемых ими инструментов (libxml2 для xmllint до того, как они были перекомпонованы в libxml2-utils) или просто доступны для целей разработки. Такие пакеты не являются сиротами. Кроме того, deborphan фокусируется на библиотеках, поэтому он пропускает ряд небиблиотечных сирот, которые могут отслеживать (устаревшие пакеты или потерянные) .
muninпо какой-то причине, но я мог потом достаточно легко это исправить.