----- Original Message -----
From: "Fabio Valentini" <decathorpe(a)gmail.com>
To: golang(a)lists.fedoraproject.org
Sent: Wednesday, March 13, 2019 10:07:35 AM
Subject: Re: [golang-dev] proposal: public module authentication with the Go notary
On Wed, Mar 13, 2019, 09:14 Nicolas Mailhot < nicolas.mailhot(a)laposte.net >
wrote:
Le 2019-03-13 03:24, Ian Denhardt a écrit :
> Quoting Nicolas Mailhot (2019-03-12 04:22:45)
>
>> > In a parallel thread, a Nix developer was asking about basically the
>> > same use case, and was pointed at `go build -mod=vendor`. It seems like
>> > this does exactly what is wanted here -- just use the code we have
>> > locally. Nicolas, does that address your use case?
>>
>> That's definitely *not* what we want (our processes call for removing
>> vendor and its equivalents in other languages before going to the
>> build step).
>
> Not sure we're on the same page re: what was suggested. The idea is
> you'd point the vendor directory at something that contains the
> distro's
> versions of the dependencies, and use -mod=vendor to bypass all of the
> smarts around fetching modules and such.
But, again, I don't *want* a vendor directory, distro or otherwise.
vendor (and GOPATH) have always been a major PITA to assemble and
maintain (and I speak as the person, that wrote at least half of the
code that assembles and maintains them Fedora-side).
Ideally, I'd like proper shared libs, because rebuilding every dependent
on changes is an obstacle to robust security (you forget one rebuild and
poof, you're owned).
Go has supported -buildmode=shared on all major architectures for some time.
I'm curious why nobody uses that yet.
Fabio
From the Fedora perspective it is due to the stability of the upstream code(API changes)
there is nearly no effective difference compared to the non shared(you will have to
rebuild "everything" anyway). I have been toying for a long time with switching
at least sdtlib to be dynamically linked in the BR, but haven't got around to push it
out(i.e. coerce maintainers to BR it, IMHO we have bigger nuts to crack atm). Other thing
is that ABI for the dynamic libs is not guaranteed between the Go releases, on other hand
with my experiments I haven't seen breaking breakages, but it is not guaranteed. I
might have been just lucky with my fairly small and simple test cases.
On practical note, nobody is barring you from BR-ing golang-shared(it currently exists on
all arches) and actually start building with dynamically linked stdlib. With current
pre-Go-module environment it should just work, you don't even need to explicitly
require it at runtime. RPM magic will require it automatically.
I guess from the regular Go user point of view is that static linking(of Go code bits) is
still the new and shining(hey I don't need any runtime deps, apart from libc), I
guess. And nobody really rediscovered all the pitfalls in production.
JC
>
>
>
> Baring that, I'd settle for a directory of modules, which was what
> GOPROXY was supposed to deliver, before Go upstream embarked in its mad
> crusade to squeeze out anything between dev and production.
>
> --
> Nicolas Mailhot
> _______________________________________________
> golang mailing list -- golang(a)lists.fedoraproject.org
> To unsubscribe send an email to golang-leave(a)lists.fedoraproject.org
> Fedora Code of Conduct:
https://getfedora.org/code-of-conduct.html
> List Guidelines:
https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
>
https://lists.fedoraproject.org/archives/list/golang@lists.fedoraproject.org
>
> _______________________________________________
> golang mailing list -- golang(a)lists.fedoraproject.org
> To unsubscribe send an email to golang-leave(a)lists.fedoraproject.org
> Fedora Code of Conduct:
https://getfedora.org/code-of-conduct.html
> List Guidelines:
https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
>
https://lists.fedoraproject.org/archives/list/golang@lists.fedoraproject.org
>