Perhaps it is just a particular challenge for distros which package on the fly, as Gentoo does.
I tried getting all the dependencies using a script to generate a list that I can pass to the ebuild. Unfortunately, some of them have been moved:
>>> Downloading 'https://proxy.golang.org//errors/@v/v0.8.0.zip'
--2020-08-18 17:38:23-- https://proxy.golang.org//errors/@v/v0.8.0.zip
Resolving proxy.golang.org... 172.217.16.81, 2a00:1450:4005:800::2011
Connecting to proxy.golang.org|172.217.16.81|:443... connected.
HTTP request sent, awaiting response... 301 Moved Permanently
Location: /errors/@v/v0.8.0.zip [following]
--2020-08-18 17:38:23-- https://proxy.golang.org/errors/@v/v0.8.0.zip
Reusing existing connection to proxy.golang.org:443.
HTTP request sent, awaiting response... 410 Gone
2020-08-18 17:38:23 ERROR 410: Gone.
>>> Downloading 'https://goproxy.io//errors/@v/v0.8.0.zip'
--2020-08-18 17:38:23-- https://goproxy.io//errors/@v/v0.8.0.zip
Resolving goproxy.io... 119.28.201.50
Connecting to goproxy.io|119.28.201.50|:443... connected.
HTTP request sent, awaiting response... 302 Found
Location: https://goproxy.onetool.net//errors/@v/v0.8.0.zip [following]
--2020-08-18 17:38:24-- https://goproxy.onetool.net//errors/@v/v0.8.0.zip
Resolving goproxy.onetool.net... 203.205.224.59, 203.205.137.254
Connecting to goproxy.onetool.net|203.205.224.59|:443... connected.
HTTP request sent, awaiting response... 404 Not Found
2020-08-18 17:38:27 ERROR 404: Not Found.
>>> Downloading 'https://gocenter.io//errors/@v/v0.8.0.zip'
--2020-08-18 17:38:27-- https://gocenter.io//errors/@v/v0.8.0.zip
Resolving gocenter.io... 35.230.74.213
Connecting to gocenter.io|35.230.74.213|:443... connected.
HTTP request sent, awaiting response... 404 Not Found
2020-08-18 17:38:28 ERROR 404: Not Found.
This causes the ebuild to fail when creating the manifest. Perhaps go handles this in a more robust manner, I don’t get errors like this when getting the deps manually.
I cannot pull the deps automatically at build time because Gentoo builds in a restricted sandbox for security reasons. The sandbox does not have network access; Gentoo expects the ebuild to provide URIs for all required sources and handles retrieval and checksumming itself, there’s no provision for letting upstream scripts do things in their own way. This is for good reasons, but obviously a problem in a case like this. Note that this wouldn’t affect binary packaging.
A Gentoo contributor suggested that I get all the dependencies manually, as the Makefile does, then put everything including deps in my own github repo and fetch from there. What do you think of that solution? What might go wrong with that approach?
It will increase the maintenance burden for the package maintainer, so it is not my favourite solution, but I am running out of ideas.