Re: [gentoo-dev] [PATCH v2 3/3] gnuconfig.eclass: use BDEPEND, BROOT where available (drop support for EAPI <4)

[Ulrich Mueller]

>>>>> 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