Date: Mon, 3 Jan 2022 14:07:47 +0100 From: marco+freebsd@crowdsec.net To: freebsd-ports@freebsd.org Subject: Go dependencies and broken port Message-ID: <CAKjC73aRuznJmeLJ4S3dTmdbdkASr_jcWmBYAueK47SH9WeSyg@mail.gmail.com>
next in thread | raw e-mail | index | archive | help
--000000000000afa6c605d4ad3538 Content-Type: text/plain; charset="UTF-8" Hello! I am in charge of maintaining the ports of security/crowdsec and security/crowdsec-firewall-bouncer, which are currently broken since a couple of weeks for not providing all Go dependencies before build time. I work for the upstream company but had little previous freebsd experience, hence the bug on my first port submission. Now, for the short term, I have submitted a fix that builds from a git tag with all vendored dependencies, and added the patch to https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=260264 I understand the previous maintainer (to whom the bug is assigned) has little time right now to review and commit again, so if somebody could have a look it would be greatly appreciated. In the long term, I'd like to avoid vendoring everything, which is not recommended by core Go devs anymore. The version of the port I inherited made use of go:modules from Mk/Uses/ go.mk, but our software has since grown some plugins as sub-projects with their own dependencies. It was a lot simpler to just call our own Makefile, as I did in https://github.com/crowdsecurity/packaging-freebsd/blob/master/security/crowdsec/Makefile My approach should then be to port the technique from go.mk to our Makefile (and run "go mod download", "go mod vendor".. by hand). A bit tricky (it would create one set of .zip and .mod for each plugin) but it should be doable. What do you think? Is there a simpler way? Thanks, Marco --000000000000afa6c605d4ad3538 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr">Hello!<br><br><div>I am in charge of maintaining the ports= of security/crowdsec and security/crowdsec-firewall-bouncer, which are cur= rently broken since a couple of weeks for not providing all Go=C2=A0 depend= encies before build time.</div><div>I work for the upstream company but had= little previous freebsd experience, hence the bug on my first port submiss= ion.<br></div><br>Now, for the short term, I have submitted a fix that builds from a git tag=20 with all vendored dependencies, and added the patch to <a href=3D"https://b= ugs.freebsd.org/bugzilla/show_bug.cgi?id=3D260264" target=3D"_blank">https:= //bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D260264</a><br><br>I understand the previous maintainer (to whom the bug is assigned) has=20 little time right now to review and commit again,=C2=A0 so if somebody coul= d=20 have a look it would be greatly appreciated.<br><br><div>In the long term, = I'd like to avoid vendoring everything, which is not recommended by cor= e Go devs anymore.</div><div>The version of the port I inherited made use o= f go:modules from Mk/Uses/<a href=3D"http://go.mk">go.mk</a>, but our software has since grown some plugins as sub-projects with=20 their own dependencies. It was a lot simpler to just call our own=20 Makefile, as I did in <a href=3D"https://github.com/crowdsecurity/packaging= -freebsd/blob/master/security/crowdsec/Makefile" target=3D"_blank">https://= github.com/crowdsecurity/packaging-freebsd/blob/master/security/crowdsec/Ma= kefile</a></div><div><br></div><div>My approach should then be to port the = technique from <a href=3D"http://go.mk">go.mk</a>; to our Makefile (and run = "go mod download", "go mod vendor".. by hand).<br></div= ><br>A bit tricky (it would create one set of .zip and .mod for each plugin)=20 but it should be doable. What do you think? Is there a simpler way?<br><br>= Thanks,<br>Marco</div> --000000000000afa6c605d4ad3538--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAKjC73aRuznJmeLJ4S3dTmdbdkASr_jcWmBYAueK47SH9WeSyg>