1 基本概念
1.1 健康的安装
在端系统中的一次健康的安装指的是，在安装的包的集合中，所有的依赖都满足，并且没有冲突存在。
这的健康的安装是相对于端系统而言的，并不是相对于整个repo而言的。对整个repo而言，肯定是存在conflict的包的。
1.2 包的可安装性
端系统中存在至少一个健康的安装，这个安装的包集合中包含这个包。
1.3 对repo的最低要求
所有的包都是可以安装的。
1.4 一个包集合是coinstallable的
如果至少存在一个健康的安装能够包含这个包集合中的所有的包，那么称之为coinstallable。
1.5 migration of a package，包迁移
包迁移说的范围是，unstable分支中的包和testing分支中的包。包括以下三个操作：
第一，unstable中的更新版本的包替换掉testing中同名的包。
第二，删除testing分支中的一个在unstable分支中已经不存在的包。
第三，将unstable中的一个新的包加入到testing分支中。
1.6 包迁移的限制条件
第一，有严重已知的bug的包不能迁移；
第二，二进制包和源码包一起迁移；
第三，包迁移版本不能降；
第四，迁移的包要有可安装性；
第五，testing分支中其它的包不能被break；
第六，一个包子集的协同安装性在迁移前后不能被破坏；
2 不稳定版本、测试版本和稳定版本
2.1 不稳定版本，即sid
这个版本永远只有一个，testing distribution的母亲。这个版本永远都不会被发布。
2.2 测试版本
它copy自old stable版本，它本次stable版本的母亲。在旧的稳定版本的基础上，脚本会自动从unstalbe版本中迁移包到测试版本中，不断生成新的测试版本。
2.3 稳定版本
一旦发布，稳定版本就不动了，除非遇到了关于安全的bug或者严重的bug。
2.4 这三个版本的关系
当testing版本到了一定的时候，会冻结一段时间，当bug被修改到一定的水平后，就会release成stable版本。
如果unstable版本中不再加入新的包，或者不在更新包，那么unstable和testing版本会越来越接近，但是由于新的包的加入，如果没有britney，unstable和testing会越来越不一样，有了britney，testing和unstable才会变得相似起来。
2.5 三个版本的进化过程
任何开发人员都可以向unstable版本中upload进新的包或者新版本的包；
在新的包或者新版本的包进入unstable之后，每天两次，自动脚本britney会试图在unstable版和testing版之间进行包迁移，迁移满足条件的包；
当debian的RM认为时间到了时，他会冻结迁移，只修改testing中的bug，当bug修改到一定的时候，就会release该testing版本成stable版本，并且拷贝一份作为新的testing版本；
当testing被冻结的时候，unstable版本仍然在开发，只不过不会向testing版本迁移。
尽管对于一个repo，判断一个包是不是可以安装是一个NP-complete的问题，但是由于生成这个repo的过程严格把关，已经保证了repo中的每个包的installability。
3 一个包可以由不稳定版迁移到测试版的条件
第一，这个包在不稳定版中已经呆了2、5、10天；
第二，这个包没有新的RC bug；
第三，这个包需要支持所有的架构；
第四，这个包不能使得已经在测试版本中的包不可用；
这一点就保证了，只要是repo中存在的包，都是可以安装的。这里的保证可用（即可以安装），是相对于端系统而言的，不是相对于repo而言的，对于repo而言，是会存在conflict存在的。比如A和B包是conflict，现在A包已经安装在端系统中了，那么安装B包的话，必须要先把A包卸载掉。也就是说，尽管它们不能共存，但是它们都是installable的。只要它们相互之间不破坏对方的这种installability就可以了。
但是，怎样保证可以尽量共存呢？怎样保证可以共存的常用包的子集合最大呢？
保证一个包可以安装很简单，只要进行piuparts测试就可以了。
第五，在测试版本冻结的时候，自动迁移过程将会被临时关闭。