I like to ask the Gentoo council to vote on whether EGO_SUM should be
reinstated ("un-deprecated") or not.
EGO_SUM is a project-comprehensive matter, as it affects not only
Go-lang packaging but also the proxy-maint and GURU projects.
Furthermore, as I have mentioned in my previous emails, the deprecation
of EGO_SUM has a significant negative impact on our users and is,
therefore, a global Gentoo issue.
Asking for council involvement should be a last resort and only be done
in essential conflicts. But, unfortunately, I was unable to convince the
relevant maintainer with arguments that the deprecation of EGO_SUM is
harmful. And this matter is significant enough to proceed with this.
Most voices on the related mailing-list threads expressed support for
reinstating EGO_SUM. At least, that is my impression. While the
arguments used to deprecate EGO_SUM were mostly of esthetic nature.
I want to state what should be common sense. Namely, asking for a
democratic vote is not a personal attack against any involved person. I
contacted the council because of a design dispute about what is best for
Gentoo and its users. Furthermore, I tried to create the best
preconditions to reinstate EGO_SUM by working on portage. For example,
making portage emit a warning if an ebuild process environment grows
unreasonably large. And after advocating for reinstating EGO_SUM for a
long time, I seek closure with that request to the council.
- Flow
On 17/04/2023 09.37, Florian Schmaus wrote:
I want to continue the discussion to re-instate EGO_SUM, potentially
leading to a democratic vote on whether EGO_SUM should be re-instated or
deprecated.
For the past months, I tried to find *technical reasons*, e.g., reasons
that affect end-users, that justify the deprecation of EGO_SUM. However,
I was unable to find any. The closest thing I could find was portage
being unable to process an ebuild due to its large environment (bug
830187). However, as this happens while developing an ebuild, it should
never affect users. Obviously this is a situation where EGO_SUM can not
be used. Fortunately, it does not affect most Go packages, as seen in my
previous analysis of Go packages in ::gentoo and their EGO_SUM size.
Furthermore, newer portage versions, with USE=gentoo-dev, will
proactively warn you if the environment caused by the ebuild becomes large.
All further arguments for the deprecation of EGO_SUM where of cosmetic
nature.
However, the deprecation of EGO_SUM is harmful to Gentoo and its users.
To briefly re-iterate the reasons:
The EGO_SUM alternatives
- do not have the same level of trust and therefore have a negative
impact on security (a dubious tarball someone put somewhere, especially
when proxy-maint)
- are not easily verifiable
- require additional effort when developing ebuilds
- hinder the packaging and Gentoo's adoption of Go-based projects, which
is worrisome as Go is very popular
- prevent Go modules from being shared as DISTFILES on the mirrors
across various packages
Last but not least, we have the same situation in the Rust ecosystem,
but we allow the EGO_SUM "equivalent" there.
So with portage checking the environment of ebuilds and warning if it
becomes too large, and with the arguments above, I do not see any reason
we should outlaw EGO_SUM.
- Flow
Previous discussions:
https://archives.gentoo.org/gentoo-dev/message/1a64a8e7694c3ee11cd48a58a95f2faa
https://archives.gentoo.org/gentoo-dev/message/d78af7f168cef24bfa302f7f75c3ef11
