Re: [gentoo-dev] EGO_SUM (was: [gentoo-project] Gentoo Council Election 202306 ... Nominations Open in Just Over 24 Hours.)

[Zoltan Puskas <zoltan@sinustrom.info>]

On Tue, Jul 04, 2023 at 01:13:30AM -0600, Tim Harder wrote:
> On 2023-07-03 Mon 04:17, Florian Schmaus wrote:
> >On 30/06/2023 13.33, Eray Aslan wrote:
> >>On Fri, Jun 30, 2023 at 03:38:11AM -0600, Tim Harder wrote:
> >>>Why do we have to keep exporting the related variables that generally
> >>>cause these size issues to the environment?
> >>
> >>I really do not want to make a +1 response but this is an excellent
> >>question that we need to answer before implementing EGO_SUM.
> >
> >Could you please discuss why you make the reintroduction of EGO_SUM 
> >dependent on this question?
> 
> Just to be clear, I don't particularly care about EGO_SUM enough to gate
> its reintroduction (and don't have any leverage to do so anyway). I'm
> just tired of the circular discussions around env issues that all seem
> to avoid actual fixes, catering instead to functionality used by a
> vanishingly small subset of ebuilds in the main repo that compels a
> certain design mostly due to how portage functioned before EAPI 0.
> 
> Other than that, supporting EGO_SUM (or any other language ecosystem
> trending towards distro-unfriendly releases) is fine as long as devs are
> cognizant how the related global-scope eclass design affects everyone
> running or working on the raw repo. I hope devs continue leveraging the
> relatively recent benchmark tooling (and perhaps more future support) to
> improve their work. Along those lines, it could be nice to see sample
> benchmark data in commit messages for large, global-scope eclass work
> just to reinforce that it was taken into account.
> 
> Tim
> 

I've been following the EGO_SUM thread for quite some time now. One other thing
I did not see mentioned in favour of EGO_SUM so far: reproducibility.

The problem with external tarballs is that they are gone once the ebuild is
dropped from the tree. Should a user ever want to roll back to a previous
version of an application, either by checking out on older version of the
portage tree or copying said ebuild into their local overlay, they still cannot
simply run an emerge on the it as they have to somehow recreate the tarball
itself too.

While upstream may not host everything forever, it's pretty much guaranteed to
be available for much longer than Gentoo's custom tarball bundles of
dependencies.

Regarding space we are also likely making trade-off. By deprecating EGO_SUM we
are saving space in the portage tree but in exchange inflating distfiles as it
will start accumulating the same dependencies potentially multiple times since
now the content is hidden in tarballs containing a combination of dependencies.
This is essentially the source file version of "statically linking".

Finally a personal opinion: I find dependency tarballs opaque. With EGO_SUM the
ebuild defines all the upstream sources it needs to build the package as well as
how to build it, but with the dependency tarball the sources are all hidden and
makes verification all that much harder.

Zoltan