为了解决台式机的空间问题，我做了一个愚蠢而鲁莽的尝试，故意删除了 Spotify，后来才/opt意识到我可以使用包管理器将其删除。删除文件夹后，我尝试使用 aptitude 清除 Spotify，但删除文件却/opt破坏了包管理器，因为缺少了预期的目录和文件。
我设法通过手动更改 aptitudes 文件、清除 Spotify 并使用 aptitude 重新安装解决了这个问题，而不必重新安装整个系统。现在我担心在我手动进行更改后，仍然有“某些东西”可能不正常，尽管一切似乎都很好。
问题： aptitude 或 dpkg 是否保存着任何数据库或平面文件，我可以在其中对它和已安装的软件包运行一致性检查，以查看它们是否关联且正常？
上述软件 (dpkg、aptitude、apt-*) 是否有机制可以帮我完成此操作？我在手册中没有看到任何内容，但我想在这里问一下，以防有人知道方法。
干杯。
答案1
你可以通过运行以下命令查看已安装软件包的几乎所有文件
dpkg -L thatpackage
或者，您也可以在http://packages.debian.org— 您在所需的发行版中选择一个包，然后在该包的页面上导航到与您的硬件架构相匹配的表格行中的“文件列表”链接。
另一个你可能感兴趣的包是debsums它能够将文件系统中属于一个软件包或一组软件包的文件与软件包元数据中记录的 MD5 哈希值进行比较。其预期用途是检测系统文件是否被篡改，但我认为，在您的案例中也可能用到它。
1有些包会动态创建某些文件和目录，但不幸的是，这不是声明式的：它们使用所谓的postinst和postrm脚本中的纯 shell 脚本来执行此操作，当包生命周期中发生某些事件时，包管理器会调用这些脚本。例如，包可能会使用以下方式生成其配置文件ucf从私人保存的模板中使用在包配置阶段从用户获得的信息，并将生成的文件安装在/etc层次结构下的某个位置。
这些属于某个包的“管道”脚本保存在/var/lib/dpkg/info层次结构下，并且名称与packagename.*模式匹配。顺便说一句，包安装的文件列表和包维护的配置文件列表保存在名为packagename.list和 的文件中，位于同一层次结构下packagename.conffiles。这是一个实现细节（更好的使用dpkg -L或类似的设备），但仍然……