1 |
On Wed, Feb 09, 2022 at 09:23:46AM +0500, Anna Vyalkova wrote: |
2 |
> On 2022-02-09 04:15, Sam James wrote: |
3 |
> > A compromise / workaround would be the Go maintainers working on |
4 |
> > some tooling to make it easier to tar up the needed modules and |
5 |
> > avoid huge SRC_URI. |
6 |
> |
7 |
> This. Sometimes EGO_SUM is so long it exceeds the maximum string length. |
8 |
> |
9 |
> *blames google for the whole go modules thing* |
10 |
|
11 |
This isn't an issue specific to Go; Rust can have the same problem. |
12 |
|
13 |
I'm speaking mostly for Go; I'm not sure how Rust handles this exactly. |
14 |
|
15 |
If we could define an extra phase function that runs after |
16 |
src_unpack, say call it src_fetch_extra, which has access to the |
17 |
network, we could completely eliminate EGO_SUM and most of the go-module |
18 |
eclass code around src_unpack. |
19 |
|
20 |
At a very high level, if src_fetch_extra is not defined, nothing |
21 |
happens. If it is defined, however, it would be called with "${S}" as |
22 |
the starting directory. |
23 |
|
24 |
Could this be added to eapi 9? |
25 |
|
26 |
If I had something like this for Go ebuilds at least, all of the big |
27 |
manifests would disappear. |
28 |
|
29 |
Thanks, |
30 |
|
31 |
William |