例如，如果我运行以下命令，dpkg -l ‘*compiz*’输出如下：
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name Version Architecture Description
+++-==============-============-============-=================================
pi compiz 1:0.9.12.2+1 all OpenGL window and compositing man
ii compiz-core 1:0.9.12.2+1 amd64 OpenGL window and compositing man
un compiz-core-ab <none> <none> (no description available)
[more output deleted]
输出有点神秘。 StackExchange上有几个详细的解释，其中，例子，是一。同样，man dpkg并man dpkg-query给出类似的解释。
在上面的示例输出中，第一个字段中的第一个字符“p”表示包的所需状态。这是包装系统认为包装应该处于的状态。
理想状态的根本含义是什么？即为什么包装管理系统知道包裹应该处于什么状态？我可以看到，如果一个包仅用作已删除的父包的依赖项，那么智能系统会建议（或希望）清除该包。然而，在我们的示例中情况并非如此。
在我们的示例中，安装了软件包“compiz”，但dpkg认为应该清除它，或者至少希望清除该软件包，这是为什么？此外，这个特定领域总体上是如何运作的？即系统如何决定包的“所需状态”以及此功能的根本原因是什么？
答案1
这p不是包装系统“认为”期望的状态应该是什么。
这就是您或其他人告诉它应该的样子 - 例如，使用像aptitude或 之类的程序synaptic，甚至是像 之类的简单实用程序apt-mark。
它被标记为在下次运行apt-get dselect-upgrade、apt-get dist-upgrade或aptitude full-upgrade类似操作时被清除。
apt 非常擅长解决依赖关系，但它不是“智能”的，它不会为你做出这样的决定。它会尽力按照您的指示去做。通常这就是有效的。有时它会因为冲突无法自动解决而退出，有时当您运行它时，它会提出删除数百个您不希望它删除的软件包，因此您必须说“不”。在这种情况下，您必须自己解决问题（借助诸如 之类的工具aptitude）。
如果您想更改compiz包的所需状态，您可以运行如下命令：
apt-mark install compiz
笔记：与包的情况一样，这将与其他包的依赖关系和冲突进行交互。例如，如果它获得该p状态是因为您过去aptitude标记了另一个要安装的软件包，而该软件包恰好与 compiz 冲突，那么就会产生依赖项冲突，在您运行 时必须解决该冲突apt-get dist-upgrade。