Debian “testing” distribution

有关 testing 发行版的基本的、面向用户的信息,请参阅 Debian FAQ

对于常规用户和 testing 的开发人员,需要注意的重要一点是:testing 的安全更新不由安全团队管理。有关更多信息,请参见安全团队 FAQ

本页面主要涵盖对 Debian 开发者来说重要的 testing 方面。

testing 是怎样工作的

testing 发行版是一个自动生成的发行版。它是由一组脚本从 unstable 发行版生成的,这些脚本试图移动很可能没有致命缺陷(release-critical bugs)的软件包。他们这样做是为了确保始终可以满足 testing 中其它软件包的依赖关系。

一个(特定版本的)软件包将在满足以下所有条件后进入 testing:

  1. 它必须已经在 unstable 中存在 10、5 或 2 天,这取决于它上传时的紧急程度;
  2. 它必须在之前 unstable 编译的所有体系架构上被编译且保持最新版本;
  3. 它不能存在致命缺陷,这些错误也不适用于已在 testing 中的当前版本(有关更多信息,请参见下文);
  4. 它的所有依赖关系都必须由已在 testing 中的软件包满足,或者由将要同时安装的一组软件包满足;
  5. 将软件包安装到 testing 中的操作不得损坏当前在 testing 中的任何软件包。(有关更多信息,请参见下文。)

满足以上前三个条件的软件包被称为 有效候选者

更新脚本显示每个软件包何时可能从 unstable 移到 testing。输出是双重的:

常问问题解答

什么是致命缺陷,它们是怎么被计数的?

默认情况下,所有具有较高严重性的错误都被认为是致命缺陷;当前,这些是紧要严重的错误。

此类错误被假定为会影响到其软件包随 Debian 的稳定发行版一起发布的机会:通常,如果一个软件包中存在被归于其下的打开的致命缺陷,它就不会移到 testing,也因此不会在 stable 发布。

testing 缺陷计数是所有被标记为应用到在 testing 中发布的体系架构里可用的软件包/版本组合致命缺陷的数量。

testing 中安装软件包可能会损坏其它软件包是怎么回事?

分发档案的结构使得它们只能包含一个软件包的一个版本;一个软件包由其名称定义。因此,将源码包 acmefoo 伴随其二进制软件包 acme-foo-binacme-bar-binlibacme-foo1libacme-foo-dev 安装到 testing 时,其旧版本将被删除。

但是,该软件包的旧版本可能提供了一个带有其依赖库的旧 soname 的二进制软件包,例如 libacme-foo0。删除旧的 acmefoo 将会删除 libacme-foo0,这将损坏所有依赖它的软件包。

显然,这主要影响提供不同版本的二进制软件包集(反过来说,主要是依赖库)的软件包。但是,这还会影响已声明 ==, <= 或 << 变体的版本依赖项的软件包。

当一个源码包提供的二进制软件包集以这种方式更改时,所有依赖于旧二进制文件的软件包都必须更新为依赖于新二进制文件。因为在 testing 安装这样的源码包会破坏 testing 中依赖它的所有软件包,所以现在必须格外小心:所有依赖的软件包都必须更新并可以自行安装,以免它们被损坏;以及,一切准备就绪后,通常需要发布管理员或助理进行手动干预。

如果您对像这样的复杂软件包组有疑问,请联系 debian-devel 或 debian-release 以获得帮助。

我还是不懂!testing 脚本说这个软件包是一个有效候选者,但它还是没有移动到 testing

当以某种方式直接或间接地安装软件包会损坏某些其它的软件包时,往往会发生这种情况。

记得要考虑您的软件包的依赖。假设您的软件包依赖于 libtool 或 libltdlX,在准备好正确版本的 libtool 之前,您的软件包将不会移动到 testing

反过来说,在安装 libtool 不会损坏已在 testing 中的东西前,移动到 testing 的情况都不会发生。换句话说,直到依赖于 libltdlY(其中 Y 是较早的版本)的所有其它软件包被重新编译,并且它们的所有致命缺陷都消失了,等等这些问题已被解决为止,所有这些软件包在此之前都不会进入 testing

这是文本形式输出 gzipped]有用的地方:它提供了提示(尽管很简洁),提示在将有效候选者添加到 testing 时哪个软件包会损坏(有关更多详细信息,请参阅 开发者参考手册)。

为什么有时难以将 Architecture: all 软件包移动到 testing

如果要安装 Architecture: all 软件包,则必须能够满足它在所有架构的依赖。如果它依赖于某些只能在 Debian 的特定体系结构上编译的软件包,那么它就不能移动到 testing

不过,暂时而言,testing 会忽略 Architecture: all 软件包在非 i386 体系结构上的可安装性。(这是一个非常 hack 的做法,我真的对此感到不高兴,但是您当然可以这样做。—aj)

因为我的软件包在某些体系结构上已过时,所以它停住了。我该怎么办?

构建日志数据库中检查您的软件包的状态。如果该软件包没有被构建出来,那它将被标记为 failed;调查构建日志并修复由您的软件包源代码引起的任何问题。

如果您偶然发现某些体系结构已经构建了您的软件包的新版本,但是未在 testing 脚本的输出中显示出来,那么您只需要耐心一点,等各个 buildd 维护者将文件上传到 Debian 软件档案库。

如果您注意到尽管您已上传了针对较早失败的修复代码,但某些体系架构还是没有构建您的软件包的新版本,那么原因可能是它被标记为等待依赖项(Dep-Wait)。您还可以查看这些被称为 wanna-build 状态的构建列表来确认。

这些问题通常最终会得到解决,但是如果您等待了较长的时间(例如两周或更长时间),请通知在移植平台网页上列出了地址的对应移植 buildd 维护者或移植平台的邮件列表。

如果您在 control 文件的体系架构列表中明确排除了某个架构,并且之前已为该架构构建了您的软件包,那么您需要请求在您的软件包能过渡到 testing 前从软件档案库中删除该架构的旧二进制软件包。您需要对 ftp.debian.org 提交一个错误报告,要求从 unstable 软件档案库中删除已排除的体系结构的软件包。一般来说,出于礼貌您应当在报告中告知相关的移植列表。

有什么例外吗?我确定尽管 acmefoo 不满足所有要求,但它已进入 testing

发布管理员在两种情形下可以覆盖规则:

你能否提供一个真实且重大的例子?

这有一个例子:当源码包 apache 与其二进制软件包 apacheapache-commonapache-devapache-doc 一起安装到 testing 时,旧版本将被删除。

但是,由于所有 Apache 模块软件包都依赖于 apache-common (>= something)、apache-common (<< something),所以这个更改将破坏所有这些依赖关系。因此,需要为新版本的 Apache 重新编译所有 Apache 模块,以便 testing 能够更新。

让我们再详细说明一下:在所有模块都更新到 unstable 以与新 Apache 一起工作后,testing 脚本尝试移动 apache-common,并发现由于模块有 Depends: apache-common (<< the current version),所以它破坏了所有 Apache 模块的依赖关系,接着尝试移动 libapache-foo 并发现由于它有 Depends: apache-common (>=the new version) 所以不能被安装。

不过,接下来他们将使用不同的逻辑(有时需要人工干预):他们将忽略 apache-common 损坏东西的事实,并继续进行可行的工作;如果在我们竭尽所能后它仍然无法正常工作,那就太糟糕了,但也许它正常工作。稍后,他们将尝试所有随机的 libapache-foo 软件包,并发现它们确实可行。

在尝试了所有方法之后,他们将检查损坏了多少个软件包,计算它是比原始软件包好还是更坏,然后接受或忽略所有更新。您能在 update_output.txt 中的 recur: 行看到此内容。

例如:

         recur: [foo bar] baz

基本上是说,已经发现 foobar 使事情变得更好,我现在正在尝试 baz 看看会发生什么,即使那会损坏东西。在 update_output.txt 中以 accepted 为开头的行表示使事情变得更好的东西,skipped 行表示使事情变得更坏的东西。

update_output.txt 文件是完全不可读的!

这不是问题。;-)

让我们举个例子:

 skipped: cln (0) (150+4)
     got: 167+0: a-40:a-33:h-49:i-45
     * i386: ginac-cint, libginac-dev

这意味着,如果 cln 进入 testing,那 ginac-cintlibginac-dev 会成为 i386 架构的 testing 中无法安装的软件包。请注意,脚本按字母顺序检查体系架构,并且仅显示第一个有问题的体系架构中的问题 — 这就是为何如此频繁地显示 alpha 架构的原因。

got 行包括在不同体系架构(到第一个发现问题的体系架构 — 见上文)上的 testing 的问题数量。i-45 意味着如果 cln 能进入 testing,那在 i386 上会出现 45 个无法安装的软件包。cln 上方和下方的一些条目显示:此时在 i386 上的 testing 有 43 个无法安装的软件包。

skipped: cln (0) (150+4) 行意味着在完成对所有软件包的检查之前,仍有 150 个软件包需要通过检查,并且已经找到了 4 个不打算更新的软件包,因为它们会破坏依赖。(0) 是无关紧要的,您可以放心地忽略它。

请注意,在一个 testing 脚本运行中对所有软件包进行了多次检查。

Jules Bean 最初组织了常问问题和解答。

附加信息

以下页面提供了有关当前 testing 的状态以及软件包从 unstable 到 testing 的迁移的附加信息:

您可能有兴趣阅读旧的解释电子邮件。它唯一的主要缺点是其没有考虑到软件包池,因为软件包池是由 James Troup 在该邮件被编写之后实现的。

testing 代码可从 ftp-master 取得。

Anthony Towns 因实现 testing 而获得赞誉。