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

[Sam James <sam@gentoo.org>]

[-- Attachment #1: Type: text/plain, Size: 2324 bytes --]


Zoltan Puskas <zoltan@sinustrom.info> writes:

> 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.

I believe Hank's email coves this.


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 377 bytes --]