Re: Patching Go software

[Jonathan Perkin <jperkin%pkgsrc.org@localhost>]

* On 2024-02-29 at 14:28 GMT, Benny Siegert wrote:

> Am 20.02.24 um 17:07 schrieb Jonathan Perkin:
> > Packaging golang software is becoming increasingly frustrating.  One 
> > of the main problems we have with the current setup is that it 
> > appears to be impossible to patch dependencies.
>
> This is indeed hard at the moment.
>
> > However, it appears that all of these extracted files are completely 
> > redundant.  During the build go will unpack its own copies from 
> > GOPROXY into ${WRKDIR}/.gopath:
>
> This is also true. The extraction is redundant, it's there because I 
> did not know how to make it skip extraction of module zip files.
>
> However! I recently raised https://github.com/golang/go/issues/64853 
> about the misleading "downloading" message during Go builds. I got the 
> feedback that we are doing the wrong thing by populating a local 
> module proxy, and that we should instead populate a GOMODCACHE with 
> extracted module contents. I still need to look into how to do that, 
> but I assume once we have that, patching dependencies will be easier.

Did you get anywhere with this?

I'm currently looking at updating my telegraf package, and unfortunately 
go software is becoming increasingly mono-cultured.  There are many 
indirect dependencies I now need to patch, previously it was "only" two.

In order to easily patch them I'm using this approach:

  * In the extract phase perform "go mod download" and "go mod vendor", 
    this unpacks all the sources into ${WRKSRC}/vendor.

  * Build with GOFLAGS="-mod=vendor".

That way I can patch the software under vendor/ and it's applied to the 
build.  However I do still end up with a lot of stuff under 
${WRKDIR}/.gopath.  

This works but would require modifying anything that has its own 
do-build target to also set GOFLAGS correctly.

--
Jonathan Perkin                    pkgsrc.smartos.org
Open Source Complete Cloud   www.tritondatacenter.com