Re: [gentoo-dev] Re: Proposal to undeprecate EGO_SUM

[Michał Górny]

On Wed, 2022-06-15 at 07:53 +0200, Michał Górny wrote:
> On Tue, 2022-06-14 at 19:03 +0200, Florian Schmaus wrote:
> > On 14.06.22 18:33, Holger Hoffstätte 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
> > Robin's post [1]), although in a broader non-Go-specific sense and it is
> > one obvious way to move forward.
> >
> > An, and probably the largest, obstacle is that this can not be
> > implemented in an eclass alone. Due the sandboxing during the build
> > process, fetching distfiles, which is what we are talking about, is the
> > package managers job and hence, I believe, this would require adustments
> > to the package manager and package manager specification (PMS).
> >
> > The basic idea, at least to my understanding (or how I would propose
> > it), is to have a new top-level ebuild variable
> >
> > SRC_URI_FILE="https://example.org/manifests/restic-0.13.1.files"
> >
> > where restic-0.13.1.files contains lines like
> >
> > <SRC_URI> <SIZE> <HASH> [<TARGET_FILENAME>]
> >
> > which is, as you nicely demonstrated on the restic ebuild, where the
> > bytes contributing to the ebuild size bloat originate from.
> >
> > Those bytes are now outsourced from ::gentoo, can be fetched on-demand,
> > allowing the package manager to download the individual distfiles into
> > DISTDIR, where an, e.g., the go eclass can process them further within
> > the constraints of the security sandbox.
> >
>
> 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".
>

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.

-- 
Best regards,
Michał Górny