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 10724158091 for ; Fri, 17 Jun 2022 19:04:14 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id AD34AE0AC2; Fri, 17 Jun 2022 19:04:09 +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 58198E0955 for ; Fri, 17 Jun 2022 19:04:09 +0000 (UTC) Message-ID: <829ce1f8c48aec7b5443f471070b75518623a270.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: Fri, 17 Jun 2022 21:04:04 +0200 In-Reply-To: <4ee362cdbcc17d76fa0edb51012bd4f6d5274858.camel@gentoo.org> References: <20220613074411.341909-1-flow@gentoo.org> <54cc5375-c8b6-3e12-81c8-a62ea308d234@applied-asynchrony.com> <47743ad6-8c4f-dc18-669c-ecf633ae5619@gentoo.org> <4ee362cdbcc17d76fa0edb51012bd4f6d5274858.camel@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: 846f3262-05e3-43a5-a539-1a3e11bbb377 X-Archives-Hash: c471dc89b2724d4060ffb2e650227346 On Wed, 2022-06-15 at 07:53 +0200, Micha=C5=82 G=C3=B3rny wrote: > 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 n= ot > > > 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 i= s=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 adustment= s=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 >=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 Just to be clear, I'm not against this proposal. In fact, I think it's probably the best solution that's been proposed so far. What I wanted to point out is that we probably don't have anyone who would actually implement that. --=20 Best regards, Micha=C5=82 G=C3=B3rny