TL; DR或“只是烧焦我的pi”
sudo apt-get remove --auto-remove --purge 'libx11-.*'
sudo apt-get autoremove --purge
（重复apt-get autoremove --purge直到没有孤儿为止）
进一步说明
如果软件包foo 依赖于另一个软件包libfoo，并且您删除了libfoo软件包，则依赖项（foo）也将被删除。因为Foo有一个指定libfoo的依赖行，所以如果删除了libfoo，则留下foo将被破坏。事实并非如此：删除foo 不会自动删除libfoo。另一个包xfoo可能还取决于libfoo，因此容易将不只是删除它（尽管如果它被安装容易将跟踪仅作为安装的副作用FOO 并主动提出删除要求，只要没有其他人仍然依赖它）
元软件包依赖于一组其他软件包，就像foo依赖libfoo一样，因此，当您删除元软件包时，通常不会删除其他软件包。例如，可能有两个依赖于xterm的元软件包（也许是lxsession和xfsession），但是卸载一个或两个都不会卸载xterm，因为没有lxsession或xfsession不会破坏xterm。通常，元软件包位于依赖关系树的顶部，而不是底层，并且几乎没有什么东西直接依赖于元软件包。元软件包主要提供一种方便的方式来立即安装一组合理的软件包，但它们不是卸载工具。
因此，如果您想烧焦所有依赖X11的内容，则需要定位所有x11应用最终必须依赖的基本libx11库集：
sudo apt-get remove --dry-run --auto-remove --purge 'libx11-.*'
sudo apt-get autoremove --dry-run --purge
这将（模拟）删除最终依赖于libx11-。*的所有内容，还将删除所有作为X11程序依赖项安装的软件包，即使它们并不直接依赖于X11本身（通常安装了CUPS和Ghostscript）作为安装桌面环境的副作用）。第二个命令将删除后续的孤儿，直到没有孤儿为止。如果要稍后执行此步骤或根本不执行此步骤，请删除“ --auto-remove”，或者在清除GUI后手动重新添加软件包。
在检查它不会删除您不打算删除的软件包之后，请删除--dry-run选项以实际执行该操作。）
我更喜欢清理和清除副作用，然后根据需要将其重新添加。另外，我继续在自己的pi上对其进行了测试，然后重新启动到了非常精简但功能正常的服务器上。:)
为什么删除会安装某些东西？
上面的策略解决了上述问题，但是仍然存在为什么执行删除操作会导致安装软件包的好奇心。
每个软件包管理器的核心都是某种可满足性的解决方案。当您告诉程序包管理器安装某些程序包，删除某些程序包或升级某些程序包时，您真正要执行的操作是在给定可用程序包集的情况下解决软件安装的下一个所需状态。该解决方案可以包括安装其他软件包（依赖项），删除现有软件包（冲突，中断），降级/升级特定软件包（兼容性级别）或其组合。因此，虽然求解器确定需要安装某些软件包才能删除其他软件包是有点违反直觉的，，这很合理。这是程序包管理器解决的棘手的依赖管理问题。
一个具体示例：给定已经安装了一组Java应用程序，它们都依赖于Java兼容的运行时，该运行时恰好是openjdk-7-jre。然后你问的软件包管理器解决安装一个新的Java工具，声明了的冲突与OpenJDK的-7的JRE，但工作与Oracle的7-JRE（两个软件包一般提供一个Java的7-运行）。求解器会提出拆除的OpenJDK的-7，JRE和安装的甲骨文的Java 7 JRE作为在不破坏现有软件包的情况下安装新软件包的理想状态的解决方案。
在这种特定情况下，xterm是一个软件包，提供了一个称为x-terminal-emulator的虚拟依赖项（xterm，lxterminal和aterm都提供了一个x-terminal-emulator），因此很可能在删除lxterminal时（作为一部分）除去LXDE），解算器中发现的现有的已安装的包（转码，需要作为一个可能的示例）某些种的x终端仿真器，所以解算器选择安装的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的软件包的简短列表。
那德博芬呢？
通过2010年“的autoremove”功能（Debian错误跟踪孤儿的功能被纳入易于得到582791渲染使用deborphan）大多是多余的，基本上是过时的。与deborphan和其他类似解决方案不同，apt-get 直接跟踪显式安装了哪些软件包，以及哪些软件包作为显式安装的软件包的副作用或依赖性而安装。例如，如果管理员安装了foo，则libfoo被安装为副作用，而apt-get autoremove 将实际上删除foo（如果在删除foo时指定了autoremove（或--auto-remove））。
deborphan采取的方法是猜测的集合。例如，猜测没有依赖库的已安装库必须是孤立的：如果安装了libfoo，但是foo和xfoo都没有，则deborphan可能会决定它必须是孤立的。此处的一种失败模式是，可能为它们提供的工具专门安装了库（在将XMLlint重新打包为libxml2-utils之前，将它们用于xmllint）或仅用于开发目的。这样的包不是孤儿。此外，deborphan专注于库，因此它错过了许多易于跟踪的非库孤儿（过时的包与孤立的包）。
munin由于某种原因也被删除了，但是之后我可以很容易地将其放回去。