当我从第三方提供的源代码构建二进制文件时，依赖项版本几乎总是存在问题。
我主要使用 Debian（有时是 Ubuntu），并且存储库只有一两个主要版本，因此我无法获得源代码所需的版本。
通常，我会执行以下操作之一：
apt-get设法从（稀有）获得我需要的版本更改
sources.list并仅更新该一个包（这似乎会破坏其他包及其依赖项）执行
dist-upgrade（我之前编译的软件停止工作，因为旧的依赖项正在被新的依赖项替换）尝试直接从第三方网站安装没有 aptitude 的依赖项
例如源要求g++5，Debian Jessie 在其存储库中只有 4 个或安装共享库，例如libboost.
管理当前发行版 aptitude 源不可用的依赖项的最佳方法是什么？
答案1
TL;DR：使用/usr/local或向后移植，并打包您自己的软件。
我将从一般性开始：发行版是一个连贯的单元。显然，它的存在是为了在合理的范围内支持用户想要在其之上执行的操作（请参阅第 4 项）Debian 社会契约），但它首先必须支持自己；特别是，它包含的库主要是因为它们是发行版中其他软件的依赖项，并且软件包-dev（或devel针对 RPM 一侧的读者）在那里，以便可以构建打包的软件使用分布。当您在发行版之上构建软件时，如果发行版中包含的库满足您的要求，那就太好了，并且非常欢迎您使用它们；但如果不这样做，您应该避免通过调整发行版来升级它们。
一些开发环境已经处理了这个问题：Python 有它的虚拟环境，Ruby 有类似的东西，Java 和 NPM 管理它们自己的特定于项目的依赖关系树，等等。C/C++ 生态系统实际上没有这样的东西，除了/usr/local，在许多情况下，这可能很符合要求，包括当编译器太旧时。
实际上，在C/C++生态系统中，有一些可行的解决方案。
如果您需要最前沿的技术，您可以使用“不稳定”的系统进行开发。它不必是您的完整系统（只有当您愿意帮助 Debian 开发其下一个版本时才应该这样做），chroot 对此非常有效；另请注意，“不稳定”指的是ABI稳定性，而不是系统的总体稳定性。
如果您愿意手动管理自己的依赖项，请在
/usr/local（并查看诸如斯托管理版本）。如果您只需要一些升级的依赖项，请考虑使用向后移植。这个答案将解释如何安装向后移植，甚至构建您自己的向后移植；这将使您能够继续以安全的方式使用比当前稳定版本更新的版本的软件包。这确实可以很好地扩展，并且许多组织在内部维护自己的向后移植包的存储库。
最重要的是，值得学习打包您正在构建的软件：这样做意味着发行版的工具将帮助您确保依赖项保持可用，这在您在其他系统上安装软件以及升级时非常有用。文森特·伯纳特 非常出色实用的 Debian 包装技术将帮助你快速到达那里。