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 53B43158091 for ; Wed, 15 Jun 2022 05:54:09 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id D3CB0E08BD; Wed, 15 Jun 2022 05:54:04 +0000 (UTC) Received: from smtp.gentoo.org (woodpecker.gentoo.org [140.211.166.183]) (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 1C194E0893 for ; Wed, 15 Jun 2022 05:54:04 +0000 (UTC) Message-ID: <4ee362cdbcc17d76fa0edb51012bd4f6d5274858.camel@gentoo.org> Subject: Re: [gentoo-dev] Re: Proposal to undeprecate EGO_SUM From: =?UTF-8?Q?Micha=C5=82_G=C3=B3rny?= To: gentoo-dev@lists.gentoo.org, Holger =?ISO-8859-1?Q?Hoffst=E4tte?= Date: Wed, 15 Jun 2022 07:53:59 +0200 In-Reply-To: <47743ad6-8c4f-dc18-669c-ecf633ae5619@gentoo.org> References: <20220613074411.341909-1-flow@gentoo.org> <54cc5375-c8b6-3e12-81c8-a62ea308d234@applied-asynchrony.com> <47743ad6-8c4f-dc18-669c-ecf633ae5619@gentoo.org> Organization: Gentoo Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.44.2 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 X-Archives-Salt: 01e9e10e-e6d7-4091-acb9-247fc979665b X-Archives-Hash: e7b6dc1f0b7db8ad087533d1007373ec On Tue, 2022-06-14 at 19:03 +0200, Florian Schmaus wrote: > On 14.06.22 18:33, Holger Hoffst=C3=A4tte wrote: > > So my idea here is: instead of chucking EGO_SUM (automatically > > generated declarative dependency management) out the window, can we not > > separate the two and instead of uploading the tarball upload the > > dependency set instead? > I think that this idea that has been pitched already (see for example=20 > Robin's post [1]), although in a broader non-Go-specific sense and it is= =20 > one obvious way to move forward. >=20 > An, and probably the largest, obstacle is that this can not be=20 > implemented in an eclass alone. Due the sandboxing during the build=20 > process, fetching distfiles, which is what we are talking about, is the= =20 > package managers job and hence, I believe, this would require adustments= =20 > to the package manager and package manager specification (PMS). >=20 > The basic idea, at least to my understanding (or how I would propose=20 > it), is to have a new top-level ebuild variable >=20 > SRC_URI_FILE=3D"https://example.org/manifests/restic-0.13.1.files" >=20 > where restic-0.13.1.files contains lines like >=20 > [] >=20 > which is, as you nicely demonstrated on the restic ebuild, where the=20 > bytes contributing to the ebuild size bloat originate from. >=20 > Those bytes are now outsourced from ::gentoo, can be fetched on-demand,= =20 > allowing the package manager to download the individual distfiles into= =20 > DISTDIR, where an, e.g., the go eclass can process them further within= =20 > the constraints of the security sandbox. >=20 Anything that involves breaking the Portage plan-depgraph / fetch&build separately would require major architectural changes, so can be rejected immediately as "not going to be implemented in our lifetimes". --=20 Best regards, Micha=C5=82 G=C3=B3rny