[Buildroot] [PATCH v2 1/2] package/pkg-golang.mk: make GOPROXY configurable

[yann.morin at orange.com]

Christian, All,

On 2025-10-20 22:09 -0700, Christian Stewart spake thusly:
> On Mon, Oct 20, 2025 at 9:34 PM <yann.morin at orange.com> wrote:
> > > - Avoid package breakages due to missing module sources
> > How can sources be missing when fetched "direct"ly?
> We had situations where Git tags were force-pushed post-facto causing breakages.

But then using a goproxy could also cause breakage if a reverse
dependency used "direct" to fetch sources from upstream after they
force-pushed the git tag, no?

For example, consider the following timeline:
  * package A tags v1
  * package B uses A-v1
  * someone grabs package B and vendors it using goproxy => goproxy
    caches A-v1
  * package A force-pushes v1 (let's call it v1´)
  * package C uses A-v1´ not using a goproxy (or a different one!)
  * someone grabs package C and vendors it using goproxy => gets the
    wrong sources...

And a go package upstream force-pushing a tag is not different for
us Buildroot than a non-go package upstream force-pushing a tag: in any
case, we end up expecting a specific hash for a tarball, but that's not
what we got, and we can't blindly update our .hash file because older
versions would be cached on s.b.o. (or the other way around for older
buildroot versions). The only sloght difference is that in one case, we
Buildroot are doing the hash check, while in the other, the go tooling
does the check...

So, using a goproxy is not a silver bullet: on average it would
introduce as many hash issues as it would solve...

[--SNIP--]
> FWIW I've overridden it to "direct" in my own Buildroot branch as I
> still prefer from-Git sources.

Yes, I believe this should be the default. Using a non-direct goproxy
could be interesting in company networks that have theire own internal
goproxy that actualy proxies to the outter internet that is otherwise
filtered.

> > > - Better alignment with upstream Go toolchain defaults
> > > - Faster downloads via the proxy compared to direct Git clones
> > > - Maintains reproducible builds through Go's module checksum validation
> >
> > In the past, we observed the reverse: the goproxy had a stale version
> > that was not matching the upstream one, so when we tried to vendor a
> > package, the hashes would not match. Using "direct" fixed the issue
> > (sorry, I can't remember what package that was...)
> I think it was the other way around, GOPROXY had the stale version yes,
> ... but the downstream dependencies of said package also expected the
> stale version.

Ah, I do remember another case, where the goproxy had a newer version,
but the reverse dependencies expected the stale one. But my memory is a
bit fuzzy about that...

In the end, it shows that using a goproxy is not a magic bullet to solve
vendoring when upstream and the goproxy disagree on the content of a
version...

Regards,
Yann E. MORIN.

-- 
                                        ____________
.-----------------.--------------------:       _    :------------------.
|  Yann E. MORIN  | Real-Time Embedded |    __/ )   | /"\ ASCII RIBBON |
|                 | Software  Designer |  _/ - /'   | \ / CAMPAIGN     |
| +33 638.411.245 '--------------------: (_    `--, |  X  AGAINST      |
| yann.morin (at) orange.com           |_="    ,--' | / \ HTML MAIL    |
'--------------------------------------:______/_____:------------------'

____________________________________________________________________________________________________________
Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.