# Information about the base meta-package

Q: Why has this been implemented so suddenly?
A: That's a good question, while we have discussed this topic multiple
times in the past and also issued a concrete proposal to arch-dev-
public (plus its follow-up summary) no further steps were taken to
get something testable. However, during arch-conf in Berlin, the
general enthusiasm and acceleration of the group was so strong, that
we have warp-10 driven this task. We acknowledge that this could have
been handled more carefully, but in the spirit of arch-conf please
excuse us and bear with us. For instance, we could have noticed
during a test phase the consequences of not having systemd-
sysvcompat. For the time being, we have added it to the base package
as the implications were not explicitly desired and discussed
beforehand, however that topic will be covered in a follow-up.

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: Why has the group been superseded by a meta-package?
A: The difference with the new base package is that this defines the
level at which we tell you, you have modified your system
sufficiently that you break it, you bought it -- it is your
responsibility to debug issues caused by your overriding basic
assumptions of the system.
This has theoretically already been the case before this change as

packages in the old `base` group were expected to be installed by a
lot of packages. On the other hand, it has never explicitly been
stated that this indeed is a requirement. The consequence is that
packages may potentially misbehave or fail to properly install.

Following this reasoning, it's a very natural choice to use a meta-
package. It allows us to reflect changes (additions or removals) in
the required package set straight on user installs with the next
system upgrade which allows preserving the consistency of those
assumptions. A simple example would be the systemd package, no matter
what use-case you have (like a tiny container) we assume you must
have systemd installed as its being relied on (sysusers, tmpdirs,
etc.).

Q: 为什么用元包（meta-package）替代了包组(group)？
A: 新的 base 包最重要的区别在于，它定义了一道界限。如果你修改你的系统超过了这个界限，
我们明确地告诉你，你搞坏了你的系统，你买单——也就是说现在是你自己的责任诊断问题修复你的系统，
因为你打破了我们对于基础系统的假设。这一点理论上来说在这次变更之前就已经是这样了，
因为原本很多包就期待系统中安装了旧的 base 组。但是另一方面，以前一直没有明确表明过那些包
是必须的依赖，后果是有些包可能不能正常运行甚至正常安装。

基于这一点，使用元包（meta-package）就成了很自然的选择。用元包让我们可以在今后对要求的包列表
做变化（增删包），下次系统升级就会直接反应这些变化，从而避免了破坏我们对系统基础包的假设。
一个简单的例子是 systemd 包，无论你的应用场景如何（就算在微型容器内）我们假定你必须安装了
systemd 因为系统很多部分需要它（像 sysusers, tmpdirs 这类）。

Q: Why has it been shrunk down and doesn't contain $package anymore?
A: The base meta-package is meant to be the lowest common denominator
across different use-cases like desktop usage, bare-metal server or
container runtime and therefore defines the foundation people can
build their desired environment upon. The old base group did not just
contain too many unnecessary packages for us to reasonably be able to
call it the lowest common denominator, it was also inconsistent (for
example it shipped reiserfsprogs but not btrfs-progs).

After reflecting on all of the feedback so far, it also became quite
clear that the old base group was kind of misused as a poor man's
installer. There is nothing wrong with such a use case per se, but if
there is a desire to solve this on our side, we should find the
optimal solution instead of just sticking to some legacy. Be it an
actual installer, something like a base-extras group, or nothing at
all, it is out of scope here, but we should look into it separately
-- so maybe its a bit of xkcd#1172.

Q: 为什么它变小了，不再包含 $package 这个包了？
A: 新的 base 元包是想要作为所有使用场景的最大公约数，使用场景包括桌面用途、
直接跑在硬件上的服务器、或者容器环境，从而它定义了大家构建自己所需环境的基础。
老的 base 组不光包含了太多不算必须的包，以至于我们没法叫它为最大公约数，并且它也没有一致性，
（比如它包含了 reiserfsprogs 但却没有 btrfs-progs）。

总结一下目前为止的反馈也能看到，以前的 base 组某种程度上被误用为简易的安装器了。
这种用法本身没什么错，但是如果说我们希望能在我们这边解决这个问题，我们应该去找最优方案
而不是一味地遵循传统。无论是提供一个真的安装器、还是一个 base-extra 的包组，
或者就这样不提供任何东西，这都在本次修改的议提之外了，我们应该单独讨论这个——或者说讨论这个有点
[xkcd#1172](https://xkcd.com/1172/) 的感觉。

Q: Why couldn't we just add a new package and leave the base group as it
was?
A: The primary reason is that base (as the name indicates) shall be the
minimal foundation and denominator of different use-cases. If we
would introduce anything other than 'base' to fulfill this job, like
base-system, base-minimal, base-foundation, or whatever one could
come up with, it wouldn't get the point across as clearly as the name
'base' itself. The historic knowledge is mostly responsible for our
bias here, but it is clearly easier to grasp the intention compared
to the difference between having `base` and `base-minimal`.

Q: 为什么就不能加一个新的包，同时保持原来的 base 组继续存在？
A: 主要原因是 base （按这个名字来说）应该是最小基础，是不同使用场景的最大公约数。
如果我们增加别的什么包而不是 'base' 来替代这个任务，无论是 base-system, base-minimal,
base-foundation 或者随便别的什么名字，它不再像 'base' 这个名字这么清晰明确。
知道历史渊源可能会让我们有倾向，但是明显比起同时有 `base` 和 `base-minimal`
并需要区分它们，现在的做法更清晰地表达意图。

Q: Should we update the dependencies of our packages to depend on base
instead of on its members?
A: Nothing has changed in that regard and there is no strict rule for do
or don't yet. This is in general more related to the topic of
transitive dependencies which needs to be discussed eventually. My
recommendation is to just keep the members that are a first-level
dependency because there is absolutely no point in making every
single package in the universe depend on the base meta-package.
However, it can be correct, clean and useful to list your first-level
dependencies explicitly instead of not at all.

Q: 我们是否需要更新包的依赖关系让它们依赖 base 包而不是依赖 base 的成员？
A: 在这方面没有任何变化，我们没有严格规则是否需要这么做。这个话题更宽泛地说，是关于是否应该有
间接包依赖关系的问题，这个我们今后会继续讨论。我的观点是保留直接依赖即可，
因为完全没必要让整个宇宙都依赖 base 元包。不过，可能显式地列出直接依赖比起不列出依赖更正确、清晰、有用。

Q: What happens next, are there any plans?
A: The most important part was getting this abstract out to provide
information and aid in resolving some of the confusion. The next
steps will include multiple follow-up topics to iterate over and
decide case by case -- for example how we want to handle systemd-
sysvcompat and other topics that emerged.

Q: 接下来呢，还有别的计划么？
A: 最重要的工作是把这个总结传达出去，帮助大家解决疑惑。接下来应该是继续一项一项地讨论剩下的议提——
比如我们应该如何处理 systemd-sysvcompat 和本次变更带来的别的讨论。

原文： https://lists.archlinux.org/pipermail/arch-dev-public/2019-October/029693.html