From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id 3C0BE15800D for ; Thu, 6 Jul 2023 06:09:46 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 737ECE087E; Thu, 6 Jul 2023 06:09:42 +0000 (UTC) Received: from mailtransmit05.runbox.com (mailtransmit05.runbox.com [IPv6:2a0c:5a00:149::26]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 496A2E0869 for ; Thu, 6 Jul 2023 06:09:41 +0000 (UTC) Received: from mailtransmit03.runbox ([10.9.9.163] helo=aibo.runbox.com) by mailtransmit05.runbox.com with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.93) (envelope-from ) id 1qHIBP-0051gW-IG for gentoo-dev@lists.gentoo.org; Thu, 06 Jul 2023 08:09:39 +0200 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=sinustrom.info; s=selector1; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:To:From:Date; bh=UbUZZ4w3ymEliAFciI7UKxSsPOZvdryHsqY9i5qMGrI=; b=sSM9d8doQ7xjcf1tcC0ru5kqiV aqdLolpS3cqXaicOS1LuBz26CmuJcISbSFF+RZbpS3WXcWjQtLdKZDuZl/Rp7N8yvqaa99d/kDcNw hkv2hmqji/Amqu7MMummvPUBLSkGlX9oNF7RFS8+RATx5w9r872D9Yz/3mJBWi8LR6Xy2ybDFhnbM xgtBoxkWXlBkuYOZw3H/jyda0/0K8jnqegGn15am2IAA1Tc5rllFFMCngEza7xJrohRxY7XfF+vvK wAchdpWkDet2Nb7KzDrmaBlsMrU3UsCOpr4sdLSnmwsYAYKtu+OZ4yBRXMuZAzX0pXZgZqpJmCwJx EW380Sng==; Received: from [10.9.9.73] (helo=submission02.runbox) by mailtransmit03.runbox with esmtp (Exim 4.86_2) (envelope-from ) id 1qHIBP-0003HO-3R for gentoo-dev@lists.gentoo.org; Thu, 06 Jul 2023 08:09:39 +0200 Received: by submission02.runbox with esmtpsa [Authenticated ID (1125710)] (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) id 1qHIB7-0002ys-NF for gentoo-dev@lists.gentoo.org; Thu, 06 Jul 2023 08:09:22 +0200 Date: Wed, 5 Jul 2023 23:09:18 -0700 From: Zoltan Puskas To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] EGO_SUM (was: [gentoo-project] Gentoo Council Election 202306 ... Nominations Open in Just Over 24 Hours.) Message-ID: <20230706060918.GA10569@tachikoma> Mail-Followup-To: gentoo-dev@lists.gentoo.org References: <2ZKWN4KF.MKEFFMWE.LGPKYP47@RTL7EJXF.RN4PF6UF.MDFBGF3C> <87y1k33aoy.fsf@gentoo.org> <5b5e5a30-6fcc-7a9d-6c91-67d9a6a5c560@gentoo.org> <87jzvl2vzh.fsf@gentoo.org> <52703145-a284-30f3-aac8-69ed086a5f4a@gentoo.org> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org X-Auto-Response-Suppress: DR, RN, NRN, OOF, AutoReply MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: X-Archives-Salt: 32aab2be-403b-42c1-81af-3e654eb6872d X-Archives-Hash: 440871dd450447befb5cbc18c894ac45 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