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

[Morten Linderud]

On Sun, Mar 15, 2020 at 01:09:19PM -0700, Anatol Pomozov via arch-dev-public wrote:
> Hello
> 
> On Sun, Mar 15, 2020 at 12:24 PM Morten Linderud via arch-dev-public
> <arch-dev-public at archlinux.org> wrote:
> >
> > On Sun, Mar 15, 2020 at 12:09:07PM -0700, Anatol Pomozov via arch-dev-public wrote:
> > > > Notice that `-mod=vendor` is also added to `GOFLAGS`.
> > >
> > > Most of the Go projects do not vendorize their dependencies to avoid
> > > polluting the source tree.
> > >
> > > And there is no point to force vendorizing in the PKGBUILD neither. go
> > > modules are doing a great job with pinning dependencies to a specific
> > > version thus eliminating the main reason for vendor'ization existence
> > > (i.e. reproducible builds).
> > >
> > > Thus following YAGNI principle I propose to drop this "-mod=vendor" flag.
> >
> > `-mod=vendor` is implicit as of go 1.14.
> 
> -mod=vendor is neither implicit nor required. -mod=vendor flag is
> enabled by default only if upstream project uses vendorized project
> structure so the build scripts do not have to add this flag manually.

I fail to see how this isn't implicit if it's enabled on the fly. This behaviour
has changed before and we really want to ensure we not downloading dependencies
during building.

We can discuss the merits of replacing `go mod vendor` with `go mod download`
and thus drop the vendor flag. However this requires packagers to realize they
don't need `prepare()` if vendor is present in the release tarballs/upstreams.

But I'd rather have this as streamlined as possible across upstreams and having
packagers think about less implicit behaviour from go.

> The decisions whether to use a vendor directory structure or not
> should be up to upstream developers.

Strictly speaking, but this is offtopic, this is up to downstream. And no, we
shouldn't be using vendored dependencies. But this is another discussion and a
issue at large in several ecosystems.

> >  We need to fetch the dependencies before over the wire before build() and
> > check().
> 
> go modules will fetch the dependencies using the information from
> go.sum. I have go packages with dependencies, and following build()
> 
> build() {
>   cd $dir
>   go build
> }
> 
> works great, including chroot environment.

I'm aware that go {list,build,test} fetches dependencies on the fly. 

And let me reiterate again; *This shouldn't happen*.

We should be capable of performing complete software builds without internet
connection. If we can't have the sources downloaded in the source array, they
need to be fetched in prepare.

This is why I'm also bringing up the prepare function in the first place.

-- 
Morten Linderud
PGP: 9C02FF419FECBE16
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://lists.archlinux.org/pipermail/arch-dev-public/attachments/20200315/5b28ba46/attachment.sig>