Re: [gentoo-dev] rfc: go 1.13 and go modules

[William Hubbs <williamh@gentoo.org>]

[-- Attachment #1: Type: text/plain, Size: 1775 bytes --]

On Mon, Sep 09, 2019 at 09:00:31PM +0200, Michał Górny wrote:
> On Mon, 2019-09-09 at 13:41 -0500, William Hubbs wrote:
> > On Mon, Sep 09, 2019 at 11:19:02AM -0700, Zac Medico wrote:
> > > On 9/9/19 10:34 AM, William Hubbs wrote:
> > > 
> > > > There is another option I want to try which is adding "go mod vendor" to
> > > > src_unpack for go packages.
> > > 
> > > If you do that then it will violate FEATURES=network-sandbox (default)
> > > unless you also do PROPERTIES+=" live".
> > > 
> > > We could add a separate PROPERTIES value for this, I've suggested it
> > > before but both Michał Górny and Ulrich Mueller were against it:
> > > 
> > > https://archives.gentoo.org/gentoo-portage-dev/message/6d696661b29b6e2b8c82061e89e4718f
> > 
> > If checksum verification is the concern, Go 1.13 also has this:
> > 
> > https://blog.golang.org/module-mirror-launch
> > 
> > Thoughts? Does this make the case for a property for these kinds of
> > ebuilds?
> > 
> 
> Checksum verification is only one of the problems.  The other one is
> that it won't work if you don't have permanent Internet access or are
> using strong firewalling.
>
> Ebuilds are using a single fetching mechanisms so that people can adjust
> it as necessary for their setup.  It's not fine to try to silently work
> around that and access Internet.

This argument is pretty irrelivent, because if you are using that strong
firewalling, you will block people from compiling go sourcewith external
dependencies whether or not they are using ebuilds.
Also, you will block emerge --sync since it uses rsync and that protocol
is more likely to be blocked than http.

This also applies to your comment about not having a permanent internet
connection.

William


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]