From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id 2D0F6138334 for ; Mon, 9 Sep 2019 22:25:51 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 50F34E0960; Mon, 9 Sep 2019 22:25:47 +0000 (UTC) Received: from mail-io1-xd2a.google.com (mail-io1-xd2a.google.com [IPv6:2607:f8b0:4864:20::d2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 05115E0940 for ; Mon, 9 Sep 2019 22:25:46 +0000 (UTC) Received: by mail-io1-xd2a.google.com with SMTP id r8so7851044iol.10 for ; Mon, 09 Sep 2019 15:25:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gentoo-org.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=/N4V8AoX/0eE/cIbRKE4QTHi38pdJsU5rYYUiTtJU4U=; b=vFYbkTDcNlIMbe29/0fzxOaH8ZfP9ROSNR79cHuLfdCiXv6kIczFn0RLaYKVdx4JKA Ri4Is3Wfb7ANFip5JYj0pAUqZyocjBJYaxW0CS3atgbKjV4iwJvgApAoTblcOT+c+DJR EGK16uRsGlFP0Cj2dQmscrCLY1RHXM4dKm17lMXCkViIsNzVe1AD9QkU4UNp2vKiGt4R QDvHQgIXKinHZKVnDo4EImvmsc7MwQRDInwCMoFWToJoyQYDM65c/Gm/hE40oifIqh20 09pibXB2Ss2MQL9lCALMS81PPCjMjDXURLM+Iqyht5mJZaFvtjKNj8Mlowlz8xUNOqfN S9qg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=/N4V8AoX/0eE/cIbRKE4QTHi38pdJsU5rYYUiTtJU4U=; b=FsDiKfFDY1CTagAk30wg4j2IO6zjqGw1+kCij4HL30vn6VCAGBllyskkrKzYOVtPMb TDQ2KXi199vkEBPRLcQ7nFO225+IdBof62muyrpYehYBl6bTdDoLBYh605V9MfbJ6ZZh N+tsVd/ppgHr0XTDQyGdJZURLhL2+qIl1MIAK//O5Laie0Hzmek6UK0oaPjpboDg3uDx tn0dijG9hgAN+PcyHnVOlKqPm6PiPheIH0tnhc/Z9CHumIHySdROFyPhB1ak34+61K53 sK2WXmCBzL+vq7kIwkmMUB4+dbXLlKY3z51IHN8gjI+aYnP9fvcKkr740DkPF9SH6zUd 21DA== X-Gm-Message-State: APjAAAVX9khOdBV3w/diuhf/f2SsH3r8Wdq0fMMeqDQ55tKsJgsfVpQX b1TgH2rcc1xP9D7uNFExULkhjuNlcQBDP6p3o+4ytosk X-Google-Smtp-Source: APXvYqyWGbiCVb3ukKwJ7MHxWeW67++aBiqY/dNNEfed/SreGQgijIWGqtZF23HGLb6u77PWZ3knnjM7OxAhC2exl5M= X-Received: by 2002:a02:7113:: with SMTP id n19mr27923868jac.82.1568067945589; Mon, 09 Sep 2019 15:25:45 -0700 (PDT) Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org X-Auto-Response-Suppress: DR, RN, NRN, OOF, AutoReply MIME-Version: 1.0 References: <20190909173418.GA30003@whubbs1.dev.av1.gaikai.org> <20190909184107.GA31538@whubbs1.dev.av1.gaikai.org> <20190909221032.GA32686@whubbs1.dev.av1.gaikai.org> In-Reply-To: <20190909221032.GA32686@whubbs1.dev.av1.gaikai.org> From: Alec Warner Date: Mon, 9 Sep 2019 15:25:34 -0700 Message-ID: Subject: Re: [gentoo-dev] rfc: go 1.13 and go modules To: Gentoo Dev , Zac Medico , Ulrich Mueller , =?UTF-8?B?TWljaGHFgiBHw7Nybnk=?= Content-Type: multipart/alternative; boundary="000000000000e17e3e05922644b3" X-Archives-Salt: 330123f0-be17-45f2-a455-c825db76723c X-Archives-Hash: 382ec9404fc53c621be273fcb522ed99 --000000000000e17e3e05922644b3 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Sep 9, 2019 at 3:10 PM William Hubbs wrote: > On Mon, Sep 09, 2019 at 09:00:31PM +0200, Micha=C5=82 G=C3=B3rny 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=3Dnetwork-sandbox > (default) > > > > unless you also do PROPERTIES+=3D" live". > > > > > > > > We could add a separate PROPERTIES value for this, I've suggested i= t > > > > before but both Micha=C5=82 G=C3=B3rny and Ulrich Mueller were agai= nst it: > > > > > > > > > https://archives.gentoo.org/gentoo-portage-dev/message/6d696661b29b6e2b8c= 82061e89e4718f > > > > > > 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 adjus= t > > 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 > > --000000000000e17e3e05922644b3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Mon, Sep 9, 2019 at 3:10 PM Willia= m Hubbs <williamh@gentoo.org&= gt; wrote:
On Mo= n, Sep 09, 2019 at 09:00:31PM +0200, Micha=C5=82 G=C3=B3rny 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 &= quot;go mod vendor" to
> > > > src_unpack for go packages.
> > >
> > > If you do that then it will violate FEATURES=3Dnetwork-sandb= ox (default)
> > > unless you also do PROPERTIES+=3D" live".
> > >
> > > We could add a separate PROPERTIES value for this, I've = suggested it
> > > before but both Micha=C5=82 G=C3=B3rny and Ulrich Mueller we= re against it:
> > >
> > > https://archives.gentoo.org/gentoo-portage-dev/message/6d696661b29b6e2b8c= 82061e89e4718f
> >
> > 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.=C2=A0 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 adju= st
> it as necessary for their setup.=C2=A0 It's not fine to try to sil= ently 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.