Q: 为什么这次变化执行得如此突然？
A: 这是个好问题，虽然我们曾经多次讨论过这个主题并且在 arch-dev-public 邮件列表发布过具体提案（以及讨论的总结），但是之后没有什么能测试的具体步骤。不过在柏林举行 [arch-conf](https://conf.archlinux.org/) 的时候，大家强烈的热情和冲动让我们对这个议程动用了 [曲速10级引擎](https://zh.wikipedia.org/wiki/%E6%9B%B2%E9%80%9F%E5%BC%95%E6%93%8E)。我们承认应该更谨慎地对待这件事，但是本着 arch-conf 精神的号召请原谅我们。比如我们本应该在测试的过程中注意到没有安装 systemd-sysvcompat 会导致的后果，后来我们也把它加入了 base 包中，因为大家不希望遇到也没有讨论过没有它导致的影响，这个话题将在今后继续讨论。
Q: 为什么用元包（meta-package）替代了包组(group)？
A: 新的 base 包最重要的区别在于，它定义了一条边界。如果你修改你的系统超过了这条边界，我们明确地告诉你，你搞坏了你的系统，你买单——也就是说现在是你自己的责任诊断问题修复你的系统，因为你打破了我们对于基础系统的假设。这一点理论上来说在这次变更之前就已经是这样了，因为原本很多包就期待系统中安装了旧的 base 组。但是另一方面，以前一直没有明确表明过那些包是必须的依赖，结果是有些包可能不能正常运行甚至正常安装。
基于这一点，使用元包（meta-package）就成了很自然的选择。用元包让我们可以在今后对要求的包列表做变化（增删包），下次系统升级就会直接反应这些变化，从而避免了破坏我们对系统基础包的假设。一个简单的例子是 systemd 包，无论你的应用场景如何（就算在微型容器内）我们假定你必须安装了 systemd 因为系统很多部分需要它（像 sysusers, tmpdirs 这类）。
Q: 为什么它变小了，不再包含 $package 这个包了？
A: 新的 base 元包是想要作为所有使用场景的最大公约数，使用场景包括桌面用途、直接跑在硬件上的服务器、或者容器环境，从而它定义了大家构建自己所需环境的基础。老的 base 组不光包含了太多不算必须的包，以至于我们没法叫它为最大公约数，并且它也没有一致性，（比如它包含了 reiserfsprogs 但却没有 btrfs-progs）。
总结一下目前为止的反馈也能看到，以前的 base 组某种程度上被误用为简易的安装器了。这种用法本身没什么错，但是如果说我们希望能在我们这边解决这个问题，我们应该去找最优方案而不是一味地遵循传统。无论是提供一个真的安装器、还是一个 base-extra 的包组，或者就这样不提供任何东西，这都在本次修改的议提之外了，我们应该单独讨论这个——或者说讨论这个有点 [xkcd#1172](https://xkcd.com/1172/) 的感觉。
Q: 为什么就不能加一个新的包，同时保持原来的 base 组继续存在？
A: 主要原因是 base （按这个名字来说）应该是最小基础，是不同使用场景的最大公约数。如果我们增加别的什么包而不是 'base' 来替代这个任务，无论是 base-system, base-minimal, base-foundation 或者随便别的什么名字，它不再像 'base' 这个名字这么清晰明确。知道历史渊源可能会让我们有倾向，但是明显比起同时有
base 和 base-minimal 并需要区分它们，现在的做法更清晰地表达意图。Q: 我们是否需要更新包的依赖关系让它们依赖 base 包而不是依赖 base 的成员？
A: 在这方面没有任何变化，我们没有严格规则是否需要这么做。这个话题更宽泛地说，是关于是否应该有间接包依赖关系的问题，这个我们今后会继续讨论。我的观点是保留直接依赖即可，因为完全没必要让整个宇宙都依赖 base 元包。不过，可能显式地列出直接依赖比起不列出依赖更正确、清晰、有用。
Q: 接下来呢，还有别的计划么？
A: 最重要的工作是把这个总结传达出去，帮助大家解决疑惑。接下来应该是继续一项一项地讨论剩下的议提——比如我们应该如何处理 systemd-sysvcompat 和本次变更带来的别的讨论。
原文： https://lists.archlinux.org/pipermail/arch-dev-public/2019-October/029693.html