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

[Eli Schwartz]

On 4/30/20 3:56 AM, Anatol Pomozov via arch-dev-public wrote:
> 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.

This RFC is about packaging code, not encouraging people to use a
particular language when writing their next big project. :p Let's focus
on that.

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

I'd like to elaborate on this again. Because I don't either understand
what the initial purpose of this RFC suggestion was.

Why does it matter to makepkg how the go compiler downloads source code,
or using which options? Any download that is done outside the source=()
array is violating the PKGBUILD contract, and is not cached in $SRCDEST.
It is therefore not persisted between successive clean chroot builds
since those use a temporary $HOME and $BUILDDIR which is deleted between
uses. And regardless of any other factors, it will not be able to work
if the makepkg tool is executed in an environment where the network has
been disabled.

So, we don't get caching and we don't get offline builds. That's beyond
question.

What is the intended goal anyone intends to solve by warming up the
gomodules download cache, precisely?

-- 
Eli Schwartz
Bug Wrangler and Trusted User

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 1601 bytes
Desc: OpenPGP digital signature
URL: <https://lists.archlinux.org/pipermail/arch-dev-public/attachments/20200430/f2348876/attachment.sig>