scrcpy努力理解Debian 测试中迁移和删除历史的逻辑（Bookworm）。
引用消息来自https://tracker.debian.org/pkg/scrcpy（为了方便起见倒序）：
- [2022-04-08] scrcpy 1.23-1 迁移到测试（Debian 测试观察）
- [2022-06-07] 接受 scrcpy 1.23-1~bpo11+1（全部来源 amd64）到 bullseye-backports、bullseye-backports（Debian FTP Masters）（签名者：Antoine Beaupré）
- 所以目前 1.23 版本已经足够好，可以用于测试和稳定向后移植，对吧？
- [2022-07-17] 接受scrcpy 1.24-1（来源）到unstable（Yangfl）（签名：Boyuan Yang）
- 测试仍然可以使用 1.23，对吗？
- [2022-07-23] scrcpy 1.24-1 迁移到测试（Debian 测试观察）
- 这到底是什么意思，即“迁移到测试”是否意味着“检查在测试中工作，因此迁移”？
- [2022-09-28] scrcpy 已从测试中删除（Debian 测试观察）
- ？！不再工作了吗？但即便如此，为什么要删除它而不是回到好的 1.23 呢？为什么向后移植不受影响，根据定义，向后移植是“从测试中获取的包”？
最后，这个问题更实际的一面：考虑到这样的情况，现在从稳定向后移植安装 1.23 到测试中是否或多或少安全？这个版本实际上并没有从测试中删除（1.24 是），所以它应该或多或少可以工作，对吗？
答案1
测试中的包自动从不稳定状态迁移一旦满足某些标准：
- 该软件包在固定天数内（在两到十天之间，取决于上传的紧急程度和是否存在软件包测试）处于不稳定状态且没有任何变化
- 该软件包已在测试中可用的所有体系结构上成功构建（用于软件包升级）
- 该包保留了测试的可安装性
- 该软件包不会引入新的错误
如果软件包引入了发布关键的错误，则可以从测试中删除它们。这就是间接发生在scrcpy:android-framework-23和其他版本上的错误，因此它们与依赖它们的所有包一起从测试中删除。软件包恢复到以前的版本是非常不寻常的，并且这种恢复必须首先经历不稳定的过程；无论如何，考虑到包的一般情况scrcpy取决于，尝试这个没有任何意义。
软件包不会迁移到向后移植，而是根据它们在测试中的存在情况手动上传到那里。
因此scrcpy自动从不稳定迁移到测试，然后上传到向后移植。由于其scrcpy依赖的其他 Android 包存在问题，随后将其从测试中删除；但向后移植的包尚未被删除（并且可能不会被删除）。目前unstable中的包也有它自己的两个发布关键错误，但这些与库依赖关系有关，并且可能不会影响向后移植的包，因为它使用稳定的包（并且是对这些包的挥之不去的依赖关系导致不稳定的问题）。
从测试系统上的稳定向后移植安装是足够安全的scrcpy，但您还需要进行稳定配置，以便可以引入库依赖项。
在这一切中，重要的是要理解测试的目标并不是成为一个完全可用的发行版；而是要成为一个完全可用的发行版。它的主要目标是成为下一个稳定版本。特别是，这意味着测试的主要目的之一是确保它包含的所有包都可以仅使用也在测试中的包来构建和安装。scrcpy在不修复其余 Android 软件包的情况下重新引入会破坏这一点。