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
