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". -- Best regards, Michał Górny
