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