根据我对 Linux 发行版的理解，您会收到更新通知，然后通过简单的单击或使用一堆命令就可以安装它们。这些可能是您之前安装的软件的补丁或次要版本更新。例如，发行版可能建议将 Firefox 版本 23 升级到 Firefox 版本 24（不好的例子，这不是次要版本，但您明白了）。然而几个月后，系统要求您进行升级：您正在更新系统本身，而不是您已安装的软件包。
为什么系统本身不能像其他软件包一样通过小规模、持续的更新来更新？
滚动发布使用什么解决方案来解决这个问题？
答案1
为什么系统本身不能像其他软件包一样通过小规模、持续的更新来更新？
正如您所注意到的，有些发行版确实可以这样工作。升级的过程本质上是一组更新；您对“更新系统本身”和“不是您安装的软件包”之间的区别有点不精确，因为系统是只是您安装的软件包。各种发行版可能有一些仅适用于升级的明确标准，但我不认为这是使用此方法的原因。我认为使用版本升级根本没有任何具体的技术原因，并且我怀疑传统版本控制发行版转换为滚动发行版需要太多时间。
我认为主要原因是区隔化。某些东西的版本 2 可能需要对版本 1 进行重大更改，而这些更改不能仅通过一系列可逆的调整来完成。因此，当您正在开发版本 2 时，可能需要继续维护不适用于版本 2 的版本 1。 差不多全部实际的软件就是这样完成的。 AFAIK，这只是软件分布它使用滚动发布模型。
此外，如果 V.2 最初被证明是惨败，用户会喜欢使用以前的版本，这一逻辑当然适用于 Linux 发行版。
滚动发布使用什么解决方案来解决这个问题？
嗯，他们对包使用版本控制。这很好，因为如上所述，系统是只不过包。所安装的任何东西都是包的一部分，因此修改系统只是集体更改一些包的问题。
对于版本化发行版，软件包实际上有两个与之关联的版本：软件包版本和发行版版本。例如，您将找到whatever.1.2.3该发行版的多个并发版本的包。我认为这为我所说的发行版之间的“重大变化”提供了相当大的灵活性。 Whatever1.2.3 可能来自相同的上游（原始）源，但在发行版 2 中配置不同，以反映相对于发行版 1 的重大架构变化。