Le 29 mars 2017 00:32:09 GMT-07:00, Baptiste Jonglez <bapti...@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