如何让我的 Debian 系统保持最新的软件包？

Question 1

想要更新的软件包是任何操作系统上的常见问题。近年来，Debian 的发布周期平均为 2 年，因此在这个周期即将结束时，这可能是一个更紧迫的问题。缓解这种情况的一种方法是在稳定发布周期结束时进行测试，此时下一个版本几乎稳定。从这个问题中尚不清楚它是否在更广泛地谈论测试和/或不稳定。无论如何，即使运行不稳定，拥有最新版本也可能是一个问题，因为最新版本可能尚未打包。 Debian 开发者/打包者是志愿者，因此他们可能会感到无聊，或者忙于其他事情，导致软件包陷入困境。

为了简单和具体，我假设接下来的计划是将包向后移植到稳定版本，但它适用于更普遍的情况。因此，如果我想要一个稳定版本中不存在的更新版本的软件，我会按大致顺序执行以下操作。

在中查找包Debian 向后移植。有时您可以找到足够新的软件包来满足您的目的。然而，通常情况下，与不稳定或实验或上游的版本相比，这些软件包已经过时。
尝试直接从测试、不稳定或实验性安装包。如果稳定版本与您尝试安装的任何版本没有太大差异，那么这可能会起作用。如果系统开始尝试从较新的版本安装或升级基本软件包，您就会知道这种方法很糟糕。假设您尝试从不稳定版本安装，那么
```
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    
```
如果由于其中一个依赖项不够新而导致失败，您需要首先向后移植该依赖项。这可能会失控。如果我必须处理超过 2 级的递归，我通常会放弃。但请注意，真正的依赖关系不一定像所说的那样严格。旧版本可能有效。打包器通常不会尝试找到可以工作的构建（或者实际上是运行时）依赖项的最旧版本。
检查来自相应上游的包的可用性。理想情况下，这些将与您的发行版相匹配，但如果需要，您也可以重建它们。
为比测试/不稳定/实验中最新的软件包更新的软件版本创建软件包。这可能相对具有挑战性，但有时仍然令人惊讶地可行。首先要注意的是，如果您尝试打包 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 似乎正在标准化
quilt上的包管理dpkg-source 3.0（被子）格式，这样有助于补丁刷新。

我将以一个现实生活中的例子来结束我如何向后移植Debian 软件包的 PGF。 pgf 的最后一个打包版本是 2008 年的 2.00，此后发布了 2.10。请参阅中的讨论请更新到最新稳定版本的 pgf (2.10)，以及我的后续错误补丁，pgf：针对 2.0 Debian 打包的补丁。事实证明，pgf 的 Debian 打包非常简单，我只需更改 2.10 打包中的一行即可使其工作。我最终平息了所有林田也有投诉，但这完全是可选的。

Answer

想要更新的软件包是任何操作系统上的常见问题。近年来，Debian 的发布周期平均为 2 年，因此在这个周期即将结束时，这可能是一个更紧迫的问题。缓解这种情况的一种方法是在稳定发布周期结束时进行测试，此时下一个版本几乎稳定。从这个问题中尚不清楚它是否在更广泛地谈论测试和/或不稳定。无论如何，即使运行不稳定，拥有最新版本也可能是一个问题，因为最新版本可能尚未打包。 Debian 开发者/打包者是志愿者，因此他们可能会感到无聊，或者忙于其他事情，导致软件包陷入困境。

为了简单和具体，我假设接下来的计划是将包向后移植到稳定版本，但它适用于更普遍的情况。因此，如果我想要一个稳定版本中不存在的更新版本的软件，我会按大致顺序执行以下操作。

在中查找包Debian 向后移植。有时您可以找到足够新的软件包来满足您的目的。然而，通常情况下，与不稳定或实验或上游的版本相比，这些软件包已经过时。
尝试直接从测试、不稳定或实验性安装包。如果稳定版本与您尝试安装的任何版本没有太大差异，那么这可能会起作用。如果系统开始尝试从较新的版本安装或升级基本软件包，您就会知道这种方法很糟糕。假设您尝试从不稳定版本安装，那么
```
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    
```
如果由于其中一个依赖项不够新而导致失败，您需要首先向后移植该依赖项。这可能会失控。如果我必须处理超过 2 级的递归，我通常会放弃。但请注意，真正的依赖关系不一定像所说的那样严格。旧版本可能有效。打包器通常不会尝试找到可以工作的构建（或者实际上是运行时）依赖项的最旧版本。
检查来自相应上游的包的可用性。理想情况下，这些将与您的发行版相匹配，但如果需要，您也可以重建它们。
为比测试/不稳定/实验中最新的软件包更新的软件版本创建软件包。这可能相对具有挑战性，但有时仍然令人惊讶地可行。首先要注意的是，如果您尝试打包 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 似乎正在标准化
quilt上的包管理dpkg-source 3.0（被子）格式，这样有助于补丁刷新。

我将以一个现实生活中的例子来结束我如何向后移植Debian 软件包的 PGF。 pgf 的最后一个打包版本是 2008 年的 2.00，此后发布了 2.10。请参阅中的讨论请更新到最新稳定版本的 pgf (2.10)，以及我的后续错误补丁，pgf：针对 2.0 Debian 打包的补丁。事实证明，pgf 的 Debian 打包非常简单，我只需更改 2.10 打包中的一行即可使其工作。我最终平息了所有林田也有投诉，但这完全是可选的。

Question 2

您当然可以构建自己的软件包，这会起作用。不过我建议使用向后移植首先，如果那里有你想要的东西。

向后移植由 Debian 维护，您可以获得它们的安全更新。

Answer

您当然可以构建自己的软件包，这会起作用。不过我建议使用向后移植首先，如果那里有你想要的东西。

向后移植由 Debian 维护，您可以获得它们的安全更新。

Question 3

构建自己的软件包是正确的方法（恕我直言）。根据软件包的 Debian 版本的年龄和变化，这可以像替换软件包描述中源 tarball 的文件名一样简单，在最坏的情况下，您仍然可以将其用作您自己版本的模板。

Answer

构建自己的软件包是正确的方法（恕我直言）。根据软件包的 Debian 版本的年龄和变化，这可以像替换软件包描述中源 tarball 的文件名一样简单，在最坏的情况下，您仍然可以将其用作您自己版本的模板。

Question 4

如果您始终需要最新版本，您会做什么？

作为已经提到过，使用向后移植。
只有一小部分 Debian 软件包被向后移植，所以我建议您使用Debian 测试。它在稳定性和新近性之间提供了很好的平衡，从某种意义上说，就像一个滚动发行版。
如果你更大胆一点，可以使用Debian 不稳定。据称它相当稳定。有些人甚至声称它比其他发行版的“稳定”版本更稳定。无论如何，不稳定是新软件包版本通常出现的地方。在迁移到测试之前，它们通常会在那里停留大约 10 天，以便进行测试。
即使使用这两个，您可能仍然发现自己没有最新版本。在这种情况下看看Debian 实验版。当新软件包对于正常存档（不稳定和测试）来说破坏性太大时，通常会使用它。
如果实验仍然没有足够新的软件版本，请查看Ubuntu 的 PPA。我在那里看到了比上述所有档案所缺少的软件版本更新的软件版本。但请谨慎使用，因为 Ubuntu 与 Debian 并非 100% 兼容（但在大多数情况下，应该不会有任何问题）。
如果上述失败，我想只需构建你自己的包，如上所述。

Answer

如果您始终需要最新版本，您会做什么？

作为已经提到过，使用向后移植。
只有一小部分 Debian 软件包被向后移植，所以我建议您使用Debian 测试。它在稳定性和新近性之间提供了很好的平衡，从某种意义上说，就像一个滚动发行版。
如果你更大胆一点，可以使用Debian 不稳定。据称它相当稳定。有些人甚至声称它比其他发行版的“稳定”版本更稳定。无论如何，不稳定是新软件包版本通常出现的地方。在迁移到测试之前，它们通常会在那里停留大约 10 天，以便进行测试。
即使使用这两个，您可能仍然发现自己没有最新版本。在这种情况下看看Debian 实验版。当新软件包对于正常存档（不稳定和测试）来说破坏性太大时，通常会使用它。
如果实验仍然没有足够新的软件版本，请查看Ubuntu 的 PPA。我在那里看到了比上述所有档案所缺少的软件版本更新的软件版本。但请谨慎使用，因为 Ubuntu 与 Debian 并非 100% 兼容（但在大多数情况下，应该不会有任何问题）。
如果上述失败，我想只需构建你自己的包，如上所述。

如何让我的 Debian 系统保持最新的软件包？

答案1

答案2

答案3

答案4

相关内容