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-pub...@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

Reply via email to