转载

Arch Linux [testing] 系列仓库简介

Arch Linux 中的 [testing]、[community-testing] 和 [multilib-testing] 三个仓库构成了 [testing] 系列仓库。由于网上许多地方对 [testing] 系列仓库存在一定的误解，我作为一只开发者，想藉此文介绍一下 [testing] 系列仓库。

一、[testing] 系列仓库里有哪些包？

主要有三类，按照数量排序应该是：由 soname 等 TODO 产生的大批 完全未经测试 的包；重要软件包、软件集合的更新、不靠谱上游推出的新版本、上游大版本更新等维护者 虽然测试过但是不敢肯定没问题 的包；因为维护者没有时间等情况而 完全未经测试 的包。注意，这里多数的情况都是完全未经测试的包，keep in mind。

二、什么情况下软件包会留在 [testing] 系列仓库里很长时间？主要也有三类：没人测试给 signoff 的；已知有问题但还未修复或不知道怎么修复还在研究的；维护者明明拿到 signoff 了（针对目标仓库是 [core] 的情况）或明明不需要 signoff（针对所有除了 [core] 以外的仓库）但还是觉得没把握的。简单来说，一般情况下你想用的新版软件不会在 [testing] 系列仓库里停留超过一个星期，除非它已经被发现有问题了。

三、开 [testing] 系列仓库需要满足什么条件？

对当前系统中所有重要资料的备份 。因为你不知道你装的下一个未经充分测试的包里是否会出现类似之前 bumblebee 或 steam 那样的灾难性错误。
有从包括 bumblebee 在内的各种灾难中恢复的能力 。几乎没有人能帮你完成这件事，所以你需要自己拥有这种能力。这里包括的不止是对修复针对性问题所需要的知识和/或找到这些知识的能力，还包括提前准备好修复工作中需要的工具，比如 USB 安装介质和你的备份。
能接受系统在一段时间内不可用 。如果你正在工作中赶进度，或者明天就需要在一场演讲中用到，这不是一个开启 [testing] 跑更新的很好时机。请保证你在满足前两个条件的情况下，还能接受你的系统需要一段时间才能修复这个事实。无论是找到问题、修复还是重装系统，还有从备份中恢复文件，都是需要一定时间的。

最后，如果读到这里还没被我吓跑，欢迎你像我一样启用 [testing] 系列仓库，并把发现的问题报告到 Arch Linux Bug Tracker 。

正文到此结束