From: William Hubbs <williamh@gentoo.org>
To: gentoo-dev@lists.gentoo.org
Subject: Re: [gentoo-dev] EGO_SUM
Date: Thu, 1 Jun 2023 14:55:00 -0500 [thread overview]
Message-ID: <ZHj3lM_lZswKHrnM@linux1.home> (raw)
In-Reply-To: <49ce8700-6c96-9360-51cf-2a989f666752@gentoo.org>
[-- Attachment #1: Type: text/plain, Size: 3947 bytes --]
I know I'm pretty late to this thread, but I'm going to respond to some
of the concerns and suggest another alternative.
On Mon, Apr 17, 2023 at 09:37:32AM +0200, 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)
For this, I would argue that vetting the tarball falls to the developer
who is proxying. If you don't trust the proxy maintainer you
are pushing for, it is easy to make a dependency tarball yourself and
add it to your dev space.
> - are not easily verifiable
I don't have a response to this other than to say that go does its
own verification of modules with the dependency tarballs that it can't
do with vendor tarballs.
> - require additional effort when developing ebuilds
This "additional effort" is pretty subjective. Making a dependency tarball
isn't a lot of work, especially with the script that I posted in this thread.
> - hinder the packaging and Gentoo's adoption of Go-based projects, which
> is worrisome as Go is very popular
I don't have a response here. I don't see it as much of a henderance
(this is obviously subjective).
> - prevent Go modules from being shared as DISTFILES on the mirrors
> across various packages
The issue here is really the duplicate data in the dependency or vendor
tarballs, and yes, there is a lot of it.
> Last but not least, we have the same situation in the Rust ecosystem,
> but we allow the EGO_SUM "equivalent" there.
I'm not sure it is quite the same because Rust projects tend to have
much smaller numbers of dependencies.
Another thing to consider is that using EGO_SUM adds a significant
amount of processing to the go-module eclass.
I was advised recently that this isn't a good idea since bash is
slow, so I am considering moving most of that processing into
get-ego-vendor by having it generate the contents of SRC_URI directly
instead of using the eclass code to do that.
My thought is to have get-ego-vendor output the value for a variable,
GO_SRC_URI and add that to SRC_URI in the ebuild like so:
# The output from get-ego-vendor:
GO_SRC_URI="
# dependency 1
# dependency 2
"
SRC_URI="https://main-project-here
${GO_SRC_URI}"
This should speed things up some since most of the processing we are
doing in the eclass would be removed, so I would rather not see the council
force the use of EGO_SUM. This, however, is still going to hit the
limitation of bug 830187.
I am, however, open to another solution, so I will keep following this
thread.
I think the better question should be around what we can do to get bug 721088 or
bug 833567 to move forward.
Thanks,
William
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]
next prev parent reply other threads:[~2023-06-01 19:55 UTC|newest]
Thread overview: 52+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-04-17 7:37 [gentoo-dev] EGO_SUM Florian Schmaus
2023-04-17 9:28 ` [gentoo-dev] EGO_SUM Anna (cybertailor) Vyalkova
2023-04-27 18:00 ` William Hubbs
2023-04-27 18:18 ` David Seifert
2023-04-24 16:11 ` Florian Schmaus
2023-04-24 20:28 ` Sam James
2023-04-24 22:52 ` Alexey Zapparov
2023-04-26 15:31 ` Florian Schmaus
2023-04-26 16:12 ` Matt Turner
2023-04-26 19:31 ` Andrew Ammerlaan
2023-04-26 19:38 ` Chris Pritchard
2023-04-26 20:47 ` Matt Turner
2023-04-27 7:58 ` Florian Schmaus
2023-04-27 9:24 ` Ulrich Mueller
2023-04-28 6:59 ` Florian Schmaus
2023-04-27 12:54 ` Michał Górny
2023-04-27 23:12 ` Pascal Jäger
2023-04-28 0:38 ` Sam James
2023-04-28 4:27 ` Michał Górny
2023-04-28 5:31 ` Sam James
2023-04-28 6:59 ` Florian Schmaus
2023-04-28 14:34 ` Michał Górny
2023-05-02 19:32 ` Florian Schmaus
2023-05-02 19:38 ` Sam James
2023-04-29 22:34 ` Robin H. Johnson
2023-04-27 21:16 ` Sam James
2023-05-02 19:32 ` Florian Schmaus
2023-05-02 19:45 ` Sam James
2023-05-08 7:53 ` Florian Schmaus
2023-05-08 12:03 ` Michał Górny
2023-05-22 7:14 ` Florian Schmaus
2023-05-02 20:04 ` Matt Turner
2023-05-08 7:53 ` Florian Schmaus
2023-04-26 20:51 ` Sam James
2023-05-30 15:52 ` Florian Schmaus
2023-05-30 16:30 ` Anna (cybertailor) Vyalkova
2023-05-31 5:02 ` Oskari Pirhonen
2023-05-30 16:35 ` Arthur Zamarin
2023-05-31 6:20 ` Andrew Ammerlaan
2023-05-31 8:40 ` Ryan Qian
2023-05-31 9:06 ` Arsen Arsenović
2023-05-31 6:30 ` pascal.jaeger leimstift.de
2023-06-01 4:00 ` William Hubbs
2023-06-02 8:17 ` Florian Schmaus
2023-06-02 8:31 ` Michał Górny
2023-06-09 10:07 ` Florian Schmaus
2023-06-01 19:55 ` William Hubbs [this message]
2023-06-02 7:13 ` [gentoo-dev] EGO_SUM Joonas Niilola
2023-06-02 18:06 ` William Hubbs
2023-06-02 18:42 ` Joonas Niilola
2023-06-09 10:07 ` Florian Schmaus
[not found] <2ZKWN4KF.MKEFFMWE.LGPKYP47@RTL7EJXF.RN4PF6UF.MDFBGF3C>
[not found] ` <be450641-94ff-a0d9-51da-3a7a3abcc6c7@gentoo.org>
[not found] ` <b7309a3f-2980-b390-a16a-0518cce1da75@gentoo.org>
[not found] ` <87y1k33aoy.fsf@gentoo.org>
2023-06-30 8:15 ` [gentoo-dev] EGO_SUM (was: [gentoo-project] Gentoo Council Election 202306 ... Nominations Open in Just Over 24 Hours.) Florian Schmaus
2023-06-30 8:22 ` Sam James
2023-07-03 10:17 ` Florian Schmaus
2023-07-03 11:12 ` [gentoo-dev] EGO_SUM Ulrich Mueller
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ZHj3lM_lZswKHrnM@linux1.home \
--to=williamh@gentoo.org \
--cc=gentoo-dev@lists.gentoo.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox