Re: [gentoo-dev] Re: Proposal to undeprecate EGO_SUM
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 > > > >[] > > > > 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 > 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
Re: [gentoo-dev] Re: Proposal to undeprecate EGO_SUM
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 > >[] > > 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 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
Re: [gentoo-dev] Re: Proposal to undeprecate EGO_SUM
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 [] 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. - Flow 1: https://archives.gentoo.org/gentoo-dev/message/8e2a4002bfc6258d65dcf725db347cb9
