On 30-04-2020 09:56, Anatol Pomozov wrote:

Hi Morten

On Sun, Apr 19, 2020 at 3:32 PM Morten Linderud via arch-dev-public arch-dev-public@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 nowadays.

...

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.. etc..

Answering on arch-general as only devs can post on arch-dev-public.

(hope I haven't broken the mail thread)

TL;DR : yes, downloading in build hurts users.

downloads during build() using gomodules are

- unpredictable as packager has no control over what is downloaded

- break reproducible builds because of their unpredictable nature.

Some other comments

- arch-meson disables downloads by default.

- most (all ?) packagers that use meson directly use --nowrap to prevent downloads.

- in the past VCS sources were downloaded in build() .

pacman devs invested lots of time and effort to allow controlling them through source array.

- git submodules work in a similar way .

The VCS packaging guidelines wiki page describes how to download the submoduile sources through     source array and add them manually in prepare().

This allows packagers to follow upstream intent but stay in control.

- gomodules are source files.

If they need to be downloaded that should happen in prepare() , not build() .

Lone_Wolf