[arch-dev-public] RFC: go-pie removal in favour of GOFLAGS

Anatol Pomozov anatol.pomozov at gmail.com
Thu Apr 30 07:56:30 UTC 2020

Hi Morten

On Sun, Apr 19, 2020 at 3:32 PM Morten Linderud via arch-dev-public
<arch-dev-public at archlinux.org> wrote:
> Yo!
> After being lazy for a few weeks, I got around to writing the new guidelines for
> Go packages. Currently it's a draft and I'd love if people read through it and
> ack/nacked
> https://wiki.archlinux.org/index.php/User:Foxboron/Go_packaging_guidelines

Thank you for coming up with this document.

Go is a fantastic language and I would love to see more people using
it. Having things documented will help our users to get more
comfortable with the golang packaging.

> The current changes is dropping anything pre-1.11 completely. I don't see the
> need to detail the GOPATH hacks as new packages should be using go modules, and
> existing packages is moving to go modules.

+1. The current "go modules" implementation is so much more superior
to what Golang had before. "go modules" is the default option

> The other changes is explicitly listing up the needed CGO_* variables needed.
> Levente pointed out CGO_CFLAGS is still needed for FORTIFY_SOURCE, so for the
> sake of completeness it's all listed.
> I have also removed `-mod=vendor` from the default listing in `prepare()` as
> Anatol wasn't fond of the idea. I'm still unsure if we really want this as we
> would be willynilly downloading sources in `build()` and `check()` during
> packaging.

My concern was related to use of vendorized sources. "-vendor" was not
created for the cache management. If one wants to warmup the gomodules
download cache then "go mod download" should be used. See more info
about this tool here https://github.com/golang/go/issues/26610

And if we plan to encourage adding the cache warmup to all golang
PKGBUILD (that's gonna be thousands of packages) then this extra
complexity need be justified. Anyone who wants to follow our advise
needs to have clear answers to following questions: Is this feature
solely to avoid the download during the build() step or there is
something else? Why downloading in build() is bad, does it hurt the
users? What use-cases does show an advantage of the cache warmup..

More information about the arch-dev-public mailing list