| 1 |
> On 7 Apr 2021, at 12:06, Ulrich Mueller <ulm@g.o> wrote: |
| 2 |
> |
| 3 |
>>>>>> On Tue, 06 Apr 2021, Sam James wrote: |
| 4 |
> |
| 5 |
>> 1) @system varies between profiles anyway which makes it hard to fully |
| 6 |
>> rely on; |
| 7 |
> |
| 8 |
> That's exactly the reason why you _don't_* add GNU grep as a dependency, |
| 9 |
> because e.g. on Prefix grep may be provided by another package. |
| 10 |
> |
| 11 |
> grep is a POSIX tool and a bootstrap package, so we can be certain that |
| 12 |
> will be available everywhere. (And the single grep instance in the |
| 13 |
> eclass doesn't use any GNUisms.) |
| 14 |
> |
| 15 |
|
| 16 |
Yeah, bootstrap package was the key distinction I was missing. |
| 17 |
|
| 18 |
>> 2) As a few of us have discussed in #gentoo-portage in the past, |
| 19 |
>> continuing this trend of not explicitly stating dependencies makes |
| 20 |
>> parallelism in Portage difficult. You can try this with |
| 21 |
>> —implicit-system-deps=n, but we really need to be stating what we use |
| 22 |
>> explicitly. |
| 23 |
> |
| 24 |
> This would mean that we'd end up with lots of system dependencies in |
| 25 |
> every ebuild. The current policy is in place for good reasons. |
| 26 |
> |
| 27 |
|
| 28 |
Yes, although as I’ll say below, I’m not sure it’s as clear as it could be. |
| 29 |
|
| 30 |
> You may have a point for adding library dependencies explicitly, but |
| 31 |
> certainly not for common build tools (aka bootstrap packages). They will |
| 32 |
> be available from the very beginning of the bootstrap process. |
| 33 |
|
| 34 |
Indeed. |
| 35 |
|
| 36 |
>> The benefit is enhanced parallelism and the downside is being |
| 37 |
>> _slightly_ more verbose in some ebuilds; |
| 38 |
> |
| 39 |
> s/slightly/much/;s/some/all/ |
| 40 |
> |
| 41 |
> We'd end up having a significant subset of profiles/base/packages in |
| 42 |
> _every_ ebuild. Or even worse, a bunch of any-of-many dependencies or |
| 43 |
> virtuals, in order to account for different systems. Personally, I |
| 44 |
> wouldn't be willing to maintain such dependencies for my ebuilds. |
| 45 |
> |
| 46 |
|
| 47 |
I’m not sure this would be a significant subset, but I agree, this |
| 48 |
approach is really only applicable to non-bootstrap dependencies. |
| 49 |
|
| 50 |
What we do need likely need is to document this specific part better. |
| 51 |
|
| 52 |
> More importantly, if you want such a policy change, then you should |
| 53 |
> discuss it first and have it approved. Until then, the current policy |
| 54 |
> [1] applies. |
| 55 |
|
| 56 |
Sure. It should probably be in the QA policy document though, given |
| 57 |
the devmanual is not always explicitly policy, as we’ve |
| 58 |
discussed. |
| 59 |
|
| 60 |
TL;DR: Agreed, I’ll drop this part from the changes, and we |
| 61 |
may revisit the issue through e.g. documentation. |
| 62 |
|
| 63 |
> |
| 64 |
>> 3) Implicit dependencies make it hard for us to ever actually swap |
| 65 |
>> implementations; |
| 66 |
> |
| 67 |
>> 4) This helps when creating minimal systems without Portage in it. |
| 68 |
> |
| 69 |
> [1] https://devmanual.gentoo.org/general-concepts/dependencies/index.html#implicit-system-dependency |
Archives