On 29-03-17 09:32, Baptiste Jonglez wrote:
So, I didn't think such a technical question would spark so much passion!
Maybe this discussion should indeed go to arch-dev-public.
In the meantime, I see 4 positions emerge from the discussion:
1) packages in "base" *should* be explicitely listed as dependencies
(either for mere "technical correctness", or because of bloat, i.e. not
everyone wants/needs all packages from "base")
2) packages in "base" *should not* be listed as dependencies (because it
is assumed that all Arch Linux systems have all packages from "base"
already installed)
3) it depends on the maintainer (i.e. there are no guidelines on this question)
4) it depends on the base package in question (e.g. it would be acceptable
to depend on glibc, but not on systemd)
I get the impression that 3) is the current status quo. I find 4) to be
quite strange and subjective, but it could be done (e.g. only allow
library dependency such as glibc, or allow all dependencies except a few
like systemd).
I have two more arguments in favour of 1) or 4), related to technical
correctness:
- when a new version of glibc is released, which packages should be
rebuilt? Without complete dependency information, I don't see how it's
possible to know.
- Assume that all "base" packages are supposed to already be installed,
and thus no other package depends on "base" packages. When a new
package X is added to "base", how is an already-running system supposed
to pick it up if no dependency pulls it in?
Baptiste
It looks like many here haven't looked at base group in a while,
or don't distinguish between base group and core repository.
example :
systemd-sysvcompat is in base, systemd is NOT .
Both are in core repo .
LW
