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

[Alec Warner]

On Mon, Sep 9, 2019 at 3:10 PM William Hubbs <williamh@g.o> wrote:

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

There are multiple ways to sync (e.g. websync, snapshots, rsync, git..) but
the idea is that you can do things like:

emerge --sync # download new tree
emerge --fetchonly # download my stuff

# Disconnect my computer
emerge foo # use downloaded stuff

You will note that there is no pkg_fetch function; the sources are all in
SRC_URI and the package-manager fetches all of them. So golang modules
would need to follow this in order to emulate this functionality or be
marked LIVE and not be able to be installed in this scheme.

I'm not quite grasping why we cannot parse the dependency syntax and build
the SRC_URIs from the dependency listing? Because its too hard? Because we
can't do it in bash? Some other reason?

-A


>
> William
>
>