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")
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
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)