On 30/09/2022 21.49, Alec Warner wrote:
On Fri, Sep 30, 2022 at 7:53 AM Florian Schmaus <f...@gentoo.org> wrote:And quite frankly, I don't see a problem with "large" Manifests and/or ebuilds. Yes, it means our FTPs are hosting many files, in some cases even many small files. And yes, it means that in some cases ebuild parsing takes a bit longer. But I spoke with a few developers in the past few months and was not presented with any real world issues that EGO_SUM caused. If someone wants to fill in here, then now is a good time to speak up. But my impression is that the arguments against EGO_SUM are mostly of cosmetic nature. Again, please correct me if I am wrong.I thought the problem was that EGO_SUM ends up in SRC_URI, which ends up in A. A ends up in the environment, and then exec() fails with E2BIG because there is an imposed limit on environment variables (and also command line argument length.) Did this get fixed? https://bugs.gentoo.org/719202
Bug #719201 was triggered by dev-texlive/texlive-latexextra-2000. It appears that the ebuild had more than 6000 entries in SRC_URI [1], from which A is generated from. Hence even a EGO_SUM limit of 3000 entries should provide enough safety margin to avoid any Golang ebuild running into this.
- Flow 1: Estimated viacurl https://raw.githubusercontent.com/gentoo-mirror/gentoo/39474128bc64d6d4738c9647dbd3b0d1c1268fc4/metadata/md5-cache/dev-texlive/texlive-latexextra-2020 | grep SRC_URI | awk -F" " '{print NF-1}'
OpenPGP_0x8CAC2A9678548E35.asc
Description: OpenPGP public key
OpenPGP_signature
Description: OpenPGP digital signature
