[arch-dev-public] Information about the base meta-package

[Levente Polyak]

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: 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: 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: 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: 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: 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.


cheers

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.archlinux.org/pipermail/arch-dev-public/attachments/20191014/3beb66dd/attachment.sig>