[gentoo-dev] Re: Flow's Manifesto and questions for nominees (was: Re: [gentoo-project] Gentoo Council Election 202306 ... Nominations Open in Just Over 24 Hours.)

[Sam James <sam@gentoo.org>]

[-- Attachment #1: Type: text/plain, Size: 4933 bytes --]


Sam James <sam@gentoo.org> writes:

> Florian Schmaus <flow@gentoo.org> writes:
>
>> [[PGP Signed Part:Undecided]]
>> Posted to gentoo-dev@ since we are now entering a technical discussion
>> again.
>>
>> For those who did not follow gentoo-project@, the previous posts include:
>>
>> https://marc.info/?l=gentoo-project&m=168918875000738&w=2
>> https://marc.info/?l=gentoo-project&m=168881103930591&w=2
>>
>> On 12/07/2023 21.28, Alec Warner wrote:
>>> On Wed, Jul 12, 2023 at 12:07 PM Florian Schmaus <flow@gentoo.org> wrote:
>>>> Apologies for not replying to everyone individually.
>>>>
>>>> I thank my fellow council candidates who took the time to reply to this
>>>> sensitive and obviously controversial matter. I understand that not
>>>> everyone feels comfortable taking a stance in this discussion.
>>>>
>>>> I asked the other council candidates about their opinion on EGO_SUM.
>>>> Unfortunately, some replies included only a rather shallow answer. A few
>>>> focused on criticism of my actions and how I approach the issue. Which
>>>> is obviously fine. I read it all and have empathy for everyone who feels
>>>> aggravated. You may or may not share the complaints. But let us focus on
>>>> the actual matter for a moment.
>>>>
>>>> Even the voices raised for a restricted reintroduction of EGO_SUM just
>>>> mention an abstract limit [1]. A concrete limit is not mentioned,
>>>> although I asked for it and provided my idea including specific limits.
>>>> Not knowing the concrete figures others have in mind makes it difficult
>>>> to find a compromise. For example, a fellow council candidate postulated
>>>> that it would be quicker for me to implement a limit-check in pkgcheck
>>>> than discuss EGO_SUM. I wish that were the case. Unfortunately it is
>
> I think this misrepresents my point. All I said was that a bound should
> be added matching what's in Portage right now.
>
> Please in future respond to me directly if you're going to claim something about what I've said.
>
>> [...]
>> EGO_SUM affects two dimensions that could be limited/restricted:
>> A) the process environment, which may run into the Linux kernel
>>    environment limit on exec(3)
>> B) the size of the package directory, where EGO_SUM affects the size of
>>    ebuilds and the Manifest
>>
>> [...]
>>
>> A), however, is a different beast. There is undeniably a
>> kernel-enforced limit that we could hit due to an extremely large
>> EGO_SUM (among other things). However, the only bug report I know that
>> runs into this kernel limit was with texlive (bug #719202). The low
>> number of recorded bugs caused by the environment limit matches with
>> the fact that even the ebuild with the most EGO_SUM entries that I
>> ever analyzed, app-containers/cri-o-1.23.1 (2022-02-16) with 2052
>> EGO_SUM entries, does *not* run into the environment limit.
>>
>
> I thought I'd gave you a list before, but maybe it was someone else.
>
> Anyway, a non-exhaustive list (I remember maybe two more but I got bored):
> * https://bugs.gentoo.org/829545 ("app-admin/vault-1.9.1 - find: The environment is too large for exec().")
> * https://bugs.gentoo.org/829684 ("app-metrics/prometheus-2.31.1 - find: The environment is too large for exec().")
> * https://bugs.gentoo.org/830187 (you're CC'd on this) ("go lang ebuild: SRC_URI too long that it causes "Argument list too long" error")
> * https://bugs.gentoo.org/831265 ("sys-cluster/minikube-1.24.0 - find: The environment is too large for exec().")
> * a0be89b772474e3336d3de699d71482aa89d2444 ("app-emulation/nerdctl: drop 0.14.0")
>

Sorry, as I said this, I came across some more. These are the ones I was
thinking of:
* https://bugs.gentoo.org/830266 ("app-admin/filebeat-7.16.2 fails to compile: Assertion failed: bc_ctl.arg_max >= LINE_MAX (xargs.c: main: 511)")
* https://bugs.gentoo.org/832964 ("sys-cluster/kops-1.21.0 fails to compile: Assertion failed: bc_ctl.arg_max >= LINE_MAX (xargs.c: main: 511)")
* https://bugs.gentoo.org/833961 ("net-p2p/go-ipfs-0.11.0 - Assertion failed: bc_ctl.arg_max >= LINE_MAX (xargs.c: main: 511)")
* https://bugs.gentoo.org/835712 ("dev-util/packer-1.7.9 fails to compile: Assertion failed: bc_ctl.arg_max >= LINE_MAX (xargs.c: main: 511)")

> Other related bugs (as it's useful as a summary of where we are):
> * https://bugs.gentoo.org/540146 ("sys-apps/portage: limit no of exported variables in EAPI 6")
> * https://bugs.gentoo.org/720180 ("sys-apps/portage: add support to delay export of "A" variable until last moment")
> * https://bugs.gentoo.org/721088 ("[Future EAPI] Don't export A")
> * https://bugs.gentoo.org/833567 ("[Future EAPI] src_fetch_extra phase the runs after src_unpack")
>
> I am not aware of a bug (yet?) for radhermit's suggestion wrt external
> helpers which is related but different to exporting fewer variables.
>
> thanks,
> sam


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 377 bytes --]