Le 29 mars 2017 00:32:09 GMT-07:00, Baptiste Jonglez <baptiste@bitsofnetworks.org> a écrit :
So, I didn't think such a technical question would spark so much passion! Maybe this discussion should indeed go to arch-dev-public.
Probably, since this is not just discussing the AUR policy but packaging at the whole scale.
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")
That’s what I’m in favour of, but there is another option you’ve forgot about that could potentially suits me as well (see below).
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)
Most of my installs consist of only few base packages installed as explicit, and probably half of base packages not being installed at all. I expect that to be a valid install, and I indeed don’t like bloat.
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.
I think that TODO for rebuilding are determined by looking at ldd output, or at least they could. But I would not make that an argument for removing glibc from depends, it will anyway be indirectly depended on for most packages.
- 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?
Which is a very good argument. Also, from the discussion there is 2.b) option, which consist in additionaly redefining base (and potentially base-devel as well, but let’s keep this separated) to really only consist of the minimal core system (maybe something in the like of pacman, glibc, systemd, linux, a shell, UNIX tools, and their dependencies). But maybe that definition of base would already be controversial/to subjective in which case we’re back to 1) being the only correct solution I would say. Bruno