Florian Schmaus <flow@gentoo.org> writes:

> Hi Sam,
>
> thanks for your feedback. I am glad for everyone who engages in this
> discussion and shares their views and new information.
>
> On 24/04/2023 22.28, Sam James wrote:
>> Florian Schmaus <flow@gentoo.org> writes:
>> [CCing williamh@ as go-module.eclass & dev-lang/go maintainer.]
>> 
>>> I like to ask the Gentoo council to vote on whether EGO_SUM should be
>>> reinstated ("un-deprecated") or not > In the various previous discussions, the need
>> for _some_ limit to be implemented (derived from EGO_SUM) was clear from
>> the QA team and others.
>
> Asking to impose an artificial limit is based on the same unfounded
> belief under which EGO_SUM was deprecated in the first place. I am
> worried that if we follow this, then a potential next step is to argue
> about adding packages to ::gentoo.
>
>
>> Voting on the matter now would be reopening the issue which led EGO_SUM
>> to be deprecated in the first place, with only a partial mitigation
>> (the Portage warning).
>
> I am sorry, but I do not follow. I think this is partly because it is
> not clear "what" (else) to mitigate.
>
> The discussion would be more productive if someone who is supporting
> the EGO_SUM deprecation could rationally summarize the main arguments
> why we deprecated EGO_SUM.

I think Matt handled this in his reply.

>
>
>> Any such limit should be supported by pkgcheck, allow using EGO_SUM
>> for most packages, but exclude the pathological cases which we're
>> unlikely to want in ::gentoo.
>> (Limit-per-ebuild rather than per-package is one option of many,
>> too.)
>
> As you probably noticed, I am not aware why we should impose such a
> limit. Especially a per-package limit confines the ability to provide
> the user with multiple versions of a package, which sometimes comes in
> handy [1].

You added a check to Portage (thank you!) to warn when the environment
size is too big. This is a runtime/dynamic check which we can't
determine purely from the repository, so pkgcheck can't notice it.

I would like pkgcheck to have an approximation of a too-large A
in an ebuild (can use Manifest as a proxy if required) derived from
the maximum environment size.

I thought I'd communicated that need for the counterpart before.

thanks,
sam