> On 7 Apr 2021, at 12:06, Ulrich Mueller <u...@gentoo.org> wrote: > >>>>>> On Tue, 06 Apr 2021, Sam James wrote: > >> 1) @system varies between profiles anyway which makes it hard to fully >> rely on; > > That's exactly the reason why you _don't_* add GNU grep as a dependency, > because e.g. on Prefix grep may be provided by another package. > > grep is a POSIX tool and a bootstrap package, so we can be certain that > will be available everywhere. (And the single grep instance in the > eclass doesn't use any GNUisms.) >
Yeah, bootstrap package was the key distinction I was missing. >> 2) As a few of us have discussed in #gentoo-portage in the past, >> continuing this trend of not explicitly stating dependencies makes >> parallelism in Portage difficult. You can try this with >> —implicit-system-deps=n, but we really need to be stating what we use >> explicitly. > > This would mean that we'd end up with lots of system dependencies in > every ebuild. The current policy is in place for good reasons. > Yes, although as I’ll say below, I’m not sure it’s as clear as it could be. > You may have a point for adding library dependencies explicitly, but > certainly not for common build tools (aka bootstrap packages). They will > be available from the very beginning of the bootstrap process. Indeed. >> The benefit is enhanced parallelism and the downside is being >> _slightly_ more verbose in some ebuilds; > > s/slightly/much/;s/some/all/ > > We'd end up having a significant subset of profiles/base/packages in > _every_ ebuild. Or even worse, a bunch of any-of-many dependencies or > virtuals, in order to account for different systems. Personally, I > wouldn't be willing to maintain such dependencies for my ebuilds. > I’m not sure this would be a significant subset, but I agree, this approach is really only applicable to non-bootstrap dependencies. What we do need likely need is to document this specific part better. > More importantly, if you want such a policy change, then you should > discuss it first and have it approved. Until then, the current policy > [1] applies. Sure. It should probably be in the QA policy document though, given the devmanual is not always explicitly policy, as we’ve discussed. TL;DR: Agreed, I’ll drop this part from the changes, and we may revisit the issue through e.g. documentation. > >> 3) Implicit dependencies make it hard for us to ever actually swap >> implementations; > >> 4) This helps when creating minimal systems without Portage in it. > > [1] > https://devmanual.gentoo.org/general-concepts/dependencies/index.html#implicit-system-dependency
signature.asc
Description: Message signed with OpenPGP
