假设我'apt-get 安装 somepkg'，然后进一步安装依赖于“somepkg”的其他软件包（“abc”和“def”）。稍后，我可能会读到软件包最新发布的源代码中有一些理想的更新，但我可以看到通过软件包管理器提供的预构建版本停留在一个非常旧的版本上，因此我从最新发布的源代码中获取、制作和安装。
但是，我现在看到我有 2 个不同版本/各种构建/安装的软件包的集合。例如/bin/somepkg-工具（v 1.0），/usr/bin/sompkg-工具(v1.0)，以及较新的、从最新的 src 构建的/usr/local/bin/somepkg-tool(v4.1)，这提出了一些问题 -
- 从不同版本安装多组二进制文件（一组来自预构建的包管理器，一组来自本地构建的最新 src）可能会出现问题吗？这感觉像是最好避免的潜在问题的根源。
- 如果我要使用 ' 删除旧的预构建托管包sudo apt-get purge somepkg'，现在提示还删除依赖包“abc”和“def”，这让我感到不舒服，因为不清楚这是否绝对必要，或者它们是否可以通过在路径上查找较新构建的二进制文件来继续工作。删除/清除以前安装的软件包是否不可避免地会删除后续的依赖包？另外，如果我接受删除依赖包，包管理器是否会看到后续（重新）安装“abc”和“def”不再需要获取和安装旧的“somepkg”，因为我已经在本地构建了并从 src 安装了必要的“somepkg”二进制文件？
- 或者是否有某种方法可以通过包管理器清除旧安装的“somepkg”没有删除2个依赖包？
- 是否有解决这种情况的通用最佳方法，或者通常最好根据具体情况进行处理？
我注意到一个类似的未回答的问题这里但是，评论集中在相当有问题的具体案例上，因为它是许多事情的基本依赖关系。
不想分散对这个问题的一般性质的注意力，说明一个具体案例可能会很有用 -
- 我'apt-get install git'（v2.30.2）
- 我后来“apt-get install gitolite3”和“... git-lfs”。
- 后来，我在发行说明中看到了许多修复/更新，我的 debian 包管理器告诉我最新的 git 包停留在旧版本上（apt-get update、apt show git），所以我“wget ...git-2.37” .3.tar.gz'，从较新的版本源制作并安装。
现在我看到我有以下二进制文件（以及 git 包附带的所有其他二进制文件）-
- /bin/git (v2.30.2老的）
- /usr/bin/git (v2.30.2老的）
- /usr/local/bin/git (v2.37.3新的）
并且希望确保避免因无意中使用较旧的 git 二进制文件而导致依赖 gitolite 存储库服务器和 LFS 服务器出现问题。因此出现了这些问题。
答案1
如果您始终知道如何
PATH设置，则可以控制它，但是，这可能是问题的根源。包管理器只知道包；它不知道您手动安装的二进制文件。
您可以使用
equivs创建一个虚拟包来满足依赖关系。看如何使 apt 忽略已安装软件包的未实现的依赖关系？看如何安装比 Debian 提供的软件更新版本的软件？以获得更好的方法，特别是对于像
git新版本这样的包已经包装好— 如果它们在向后移植中不可用（Debian 11 目前为 2.34.1），您可以使用较新的源包重建实际的包。
答案2
使用两个不同的安装系统（来自包管理器并由本地管理员“手动”编译/安装），很容易得到：
- 主命令/守护进程位于两个不同的地方。一些用户找到一个地方，其他人找到另一个地方，版本的差异导致行为的差异 - 让所有用户感到困惑。对于用户可以自行停止和启动的守护程序来说尤其如此。
- 配置目录/文件位于两个不同的位置，当有人更新他们不使用的版本的配置文件时，会引起投诉。
- 对于守护程序，两个版本的日志文件通常写入两个不同的位置，从而导致混乱并延迟用户或服务器管理员的调试或故障排除工作。
尽可能避免手动安装重复的程序。如果您必须这样做，请创建大量文档来说明您以这种方式安装了哪些程序以及如何编译/安装它们。向包管理器添加配置以防止它安装您不需要的包（在这些配置中包含详细注释）也是一件重要的事情。让您之后的下一个系统管理员可以轻松维护和更新这些程序。 （通常“下一个”管理员将是你，在9个月后这些细节的记忆已经消失）