On Wed, Apr 26, 2023 at 3:31 PM Andrew Ammerlaan <andrewammerl...@gentoo.org> wrote: > > On 26/04/2023 18:12, Matt Turner wrote: > > On Wed, Apr 26, 2023 at 11:31 AM Florian Schmaus <f...@gentoo.org> wrote: > >> 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. > > > > You're requesting the changes. It's on you to read the previous > > threads and try to understand. It's not others' responsibilities to > > justify the status quo to you, but tl;dr is Manifest files grew to > > insane sizes for golang packages with many dependencies, and the > > Manifest size is a cost all Gentoo users pay regardless of whether > > they use the package. > > > > This is a valid point and I think it is clear. What is not clear however > is why the EGO_SUM method should be dropped entirely instead of keeping > it as an option for overlays (with an appropriate warning). As I > remember this is where the discussion got 'stuck' last time. > > There are other cases where things are possible but prohibited in > ::gentoo by policy. E.g. the acct-user eclass allows setting > ACCT_USER_ID to -1 for dynamic assignment, but we do not allow this in > ::gentoo. I don't see why we could not do the same for EGO_SUM, keep it > as an option, while disallowing it in ::gentoo.
I suspect allowing it unrestricted in overlays is fine—which seems to be the major practical issue that spurred this thread. Sam suggested a requirement for a maximum Manifest size (presumably thinking about ::gentoo), and Florian replied: > 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. So I think that's where the disagreement is.
