>>>>> 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.) > 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. 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. > 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. 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. > 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: PGP signature
