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

[Lone_Wolf]

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