Sam James writes: > Florian Schmaus 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 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