On 14/07/2023 09.33, Sam James wrote:
Florian Schmaus <f...@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 <f...@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 isI 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")
Thanks for providing this valuable information, Sam. I was indeed not aware of those bugs. They all seem to be fixed before 2022-02-16, that is the date of the ::gentoo tree I mostly analyzed (which was selected because it was just before EGO_SUM was deprecated).
Limiting the process environment to 90% of the kernel-enforced limit, as antarus also suggested (potentially by approximating the EGO_SUM entries) would have probably prevented those bugs. As I previously wrote, I would be happy to work on a pkgcheck for that, if the limit is only about the kernel's process environment limit (A).
However this still leaves us with some that seem to also demand a limit with regard to the package-directory size (B).
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.
Improving, that is, reducing, what portage exports to child processes of the ebuild is sensible. But it is only indirectly related to EGO_SUM and not a strict prerequisite to re-introduce EGO_SUM.
- Flow
OpenPGP_0x8CAC2A9678548E35.asc
Description: OpenPGP public key
OpenPGP_signature
Description: OpenPGP digital signature
