我在服务器上安装的大多数“软件”都必须是最新版本（Java，Tomcat，MySQL-Cluster）。因此，我从来没有运气，因为有预构建的Debian软件包（在发行版中）可用。因此，所有软件均从项目网页下载并从源代码构建。
现在我的问题是，在我的Debian系统上安装它们的正确方法是什么？
我的主要问题是，直接从源代码安装它们时，它们不包含在程序包管理中（有能力）。似乎不建议真正使用Checkinstall，并且Equiv也有缺点。通过dh_make和dpkg-buildpackage构建我自己的软件包是解决此问题的唯一正确方法吗？
如果您始终需要最新版本，该怎么办？
Answers:
想要更新的软件包是任何操作系统上的常见问题。近年来，Debian的发布周期平均为2年，因此在此周期快要结束时，这也许是一个更加紧迫的问题。缓解此问题的一种方法是在下一个版本几乎稳定时，在稳定发行周期结束时进行测试。从这个问题尚不清楚，它是否更一般地说是关于测试和/或不稳定。无论如何，即使运行不稳定，即使拥有最新版本也可能会成为问题，因为最新版本可能尚未打包。Debian开发人员/打包人员是志愿者，因此他们可能会感到无聊或忙于其他事情，结果导致打包程序瘫痪。
为了简单和具体，我在接下来的内容中假设该计划是将程序包反向移植到稳定版，但它适用范围更广。因此，如果我想要一个不稳定的，近似的顺序的较新版本的软件，这就是我应该做的。
在Debian Backports中寻找软件包。有时，您会找到最新的软件包，可以满足您的目的。但是，与不稳定或实验性或上游的版本相比，这些软件包通常是过时的。
尝试直接从测试，不稳定或实验性安装软件包。如果稳定版与您要安装的版本没有太大差异，则可能会起作用。如果系统开始尝试从较新版本安装或升级基本软件包，您就会知道这种方法是一种不好的方法。假设您尝试从不稳定版本进行安装，然后
apt-get install packagename/unstable
是第一件事。使用apt稳定版时，这通常会失败，因为它需要来自不稳定的其他软件包，而这种诱惑只会增加packagename足够高的偏好，以便将其安装在不稳定的环境中。如果您不明白这意味着什么，请走走阅读man
apt_preferences。继续添加来自不稳定对象的依赖项，确保它没有尝试升级基本软件包。例如，如果它开始尝试升级libc6或X或KDE或Gnome，请立即中止。如果尝试从同一源软件包升级其他软件包，通常会很好，因为它们通常紧密地结合在一起。要查看二进制包所依赖的源包，请执行
apt-cache showsrc packagename
由于很多东西都依赖于GNU C库（libc6），因此这曾经是一个问题。最近，API似乎已经稳定下来，因此现在可以不必升级就可以摆脱它。如果程序包满足其稳定的运行时依赖关系，但仍无法正常工作，请提交错误。如果打包程序告诉您这不是错误，则它们是错误的。:-)
自己退回测试，不稳定或试验性包装。
如上所述，反向移植是一种选择，但是与不稳定或实验性或上游的版本相比，这些软件包通常已过时。
这通常可能需要递归依赖关系构建循环类型的东西。您首先需要获取构建依赖关系
apt-get build-dep packagename
如果由于其中一个依赖关系不够新而导致失败，则需要先反向移植该依赖关系。这可能会使您失去控制。如果必须处理两个以上级别的递归，我通常会放弃。但是请注意，实际的依赖关系并不一定像陈述的那样严格。较旧的版本可能会起作用。打包程序通常不尝试查找将起作用的最旧版本的构建（或实际上是运行时）依赖项。
从相应的上游检查软件包的可用性。理想情况下，它们将与您的发行版匹配，但是如果需要，您也可以重新构建它们。
创建比测试/不稳定/实验中的最新软件包更新的软件版本软件包。这可能是相对具有挑战性的，但有时仍然出奇地可行。首先要注意的是，如果您要打包Debian中已经存在的软件包的较新版本，那么您已经有了一个很大的优势，那就是可以使用现有的打包软件。做就是了
apt-get source packagename
和apt-get将下载对应的源包，包括Debian的子目录，其中所述包装的生活。还要注意的是，如今，这种包装通常位于某些版本控制库（git在Debian中似乎很流行）中，而稳定的apt（当前为0.8.10.3）有助于告诉您调用时这在哪里
apt-get source。您应该注意这一点，因为打包程序的打包版本可能比对应于任何已发布的打包程序的版本都要新。例如。
$ apt-get source mercurial
Reading package lists... Done
Building dependency tree
Reading state information... Done
NOTICE: 'mercurial' packaging is maintained in the 'Svn' version control system at:
svn://svn.debian.org/python-apps/packages/mercurial/trunk
或者，您可以简单地使用
apt-cache showsrc mercurial | grep Vcs
列出存储库。
如果软件包严重过时，则可能必须对
软件包进行修改，刷新所应用的补丁，但是通常这仍然是一个不错的起点
。Debian似乎正在
按照dpkg-source 3.0（quilt）格式对被子上的软件包管理进行标准化，以帮助刷新补丁。
我会用我如何反向移植了一个真实的例子得出结论：Debian软件包的 PGF。pgf的最后一个打包版本是2008年，版本是2.00，此后发布了2.10。请参阅“ 请更新到pgf（2.10）的最新稳定版本”中的讨论，以及我的后续错误以及pgf：针对2.0 Debian打包的补丁。事实证明，pgf的Debian打包非常简单，我只需要在2.10打包中更改一行即可使其工作。我最终平息所有的 林田投诉为好，但这是可选的。
如果您始终需要最新版本，该怎么办？
正如已经提到的，使用反向移植。
仅反向移植了Debian软件包的一小部分，因此建议您使用Debian Testing。它在稳定性和新近度之间提供了很好的平衡，并且在某种意义上就像滚动发行版。
如果您更勇敢，请使用Debian Unstable。据称是相当稳定的。甚至有人声称它比其他发行版的“稳定”发行版更稳定。无论如何，不稳定是通常进入新软件包版本的地方。他们通常会在那里呆大约10天，以便进行测试，然后再迁移到“测试”。
即使使用这两个版本，您仍可能会发现自己没有最新版本。在这种情况下，请查看Debian实验版。当新软件包对常规存档的破坏性太大（不稳定和测试）时，通常使用它。
如果“实验”仍没有足够新的软件版本，请查看Ubuntu的PPA。我看到的软件版本比上述所有归档文件所缺少的版本都要新。但是请谨慎使用，因为Ubuntu与Debian并非100％兼容（但在大多数情况下，应该没有任何问题）。
如果以上方法都失败了，我想就可以像上面提到的那样构建自己的软件包。