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 BEE4C15800D for ; Tue, 4 Jul 2023 10:45:01 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 434A6E08C8; Tue, 4 Jul 2023 10:44:58 +0000 (UTC) Received: from mail.flump.de (flump.de [185.163.118.210]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 01C4BE0899 for ; Tue, 4 Jul 2023 10:44:57 +0000 (UTC) Received: from falbala.localnet (ip4d166edb.dynamic.kabel-deutschland.de [77.22.110.219]) by mail.flump.de (Postfix) with ESMTPSA id 8CEB28C0463 for ; Tue, 4 Jul 2023 12:44:52 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=flump.de; s=mail; t=1688467492; bh=+1Zk9v7YbUYOk1fHXG8OQ2Vn7BN6hbqIGrdPn05crTM=; h=From:To:Subject:Date:In-Reply-To:References; b=Gy9V0jLxFcU+eUv2tx4tMPCajIT1c4jnBdsYGFH6LtKyZESBO1xFVT0wGCOKUa6QL 2xSDQkcTkAmCzyI4laPemSwihdCZHV2aKDIM3tFMq8bCLDS5jCt2cTnSOMnJf+Ae3U g891VQaUQM1TtUkfor7rLzY73mLKMnJkm25dE7Ks= From: Gerion Entrup 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.) Date: Tue, 04 Jul 2023 12:44:39 +0200 Message-ID: <1940209.tdWV9SEqCh@falbala> In-Reply-To: References: <2ZKWN4KF.MKEFFMWE.LGPKYP47@RTL7EJXF.RN4PF6UF.MDFBGF3C> <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: multipart/signed; boundary="nextPart2232234.irdbgypaU6"; micalg="pgp-sha256"; protocol="application/pgp-signature" X-Archives-Salt: 61a04401-0111-4c39-910a-15242a0863fe X-Archives-Hash: 7b205b635ad6d4a29d25bc82962ded29 --nextPart2232234.irdbgypaU6 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii"; protected-headers="v1" From: Gerion Entrup To: gentoo-dev@lists.gentoo.org Date: Tue, 04 Jul 2023 12:44:39 +0200 Message-ID: <1940209.tdWV9SEqCh@falbala> In-Reply-To: MIME-Version: 1.0 Am Dienstag, 4. Juli 2023, 09:13:30 CEST schrieb Tim Harder: > 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 Hi, just to be curious about the whole discussion. I did not follow in the deepest detail but what I got is: - EGO_SUM blows up the Manifest file, since every little Go module needs to be respected. A lot of these Manifest files lead to a extremely increased Portage tree size. EGO_SUM is just one example (though the biggest one). Statically linked languages like Rust etc. have the same problem. - The current solution is to prepackage all modules, put it somewhere on a webserver and just manifest that file. This make the Portage tree small in size again, but requires a webserver/mirror and is thus unfriendly for overlay devs. I'm not sure if it was mentioned before but has anyone considered hash trees / Merkle trees for the manifest file? The idea would be to hash the standard manifest file a second time if it gets too big and write down that hash as new manifest file and leave EGO_SUM as is. When Portage tries to install the package, it can download all modules, build the "normal" Manifest file like normally, but instead of directly compare it to the Manifest in the tree it can hash it again and compare that to the provided Manifest. With this, Portage should have more less the same guarantees about the validity of the source code, but the manifest file consists of just two hashes again. What one would loose is the direct comparison of file names (they are included in the "meta"-hash, though) or do I miss something? Gerion --nextPart2232234.irdbgypaU6 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- iQGzBAABCAAdFiEEM/tVN9WpYYHnPZHxloeAdSYJHeoFAmSj+BcACgkQloeAdSYJ HerobAwAg2CO8kDVsldIAn8ni6RBxgZ71DSNPcBC8V/eZszElcIWPuxylqyYyWf4 50zVbXPzacXCV9uh6W0NJtWITXA/qdtK3LoKnC2Z6d4lS6AWmk7IbAeIltomPEsc LFk/qbWJvYU6OF14ICPgWD188+pJrwtFQen3uRQyye1cZ2i+B1DjYjaYO5ig69Ct W/Rod27hQnL6rP8lXj9eOLuEWC2sY7JvzhmJG4VWt6npymcMu59ypoHpiYGR1VQK W1RDGFc/Bd6+XixE8dkRGlisrKFH67uh5G8l3+O6ButxBo+4tRCuqnbjd50AM+Go hrIDqc3RnM9F9/uPQeY9+X8X7RJlrACTmxvov5sgq943sq7pfovqCkEakjCC499v xACmS2Io7hyYDW9KeZPCBJJ6iaJiktsK6Ue7JMmMnOgSZhNvn/M/QICRgESrhbng AP5nhF3p4CQkyhbFWPrkQejVg6jF4tYMwQiPvB3D02wJp5AOos3o0PynoBYsGeXR IE6DB15U =IjWu -----END PGP SIGNATURE----- --nextPart2232234.irdbgypaU6--