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 CFE2A138334 for ; Sat, 14 Sep 2019 17:07:11 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 6D2A5E089F; Sat, 14 Sep 2019 17:07:07 +0000 (UTC) Received: from mail-io1-xd41.google.com (mail-io1-xd41.google.com [IPv6:2607:f8b0:4864:20::d41]) (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 1491BE0886 for ; Sat, 14 Sep 2019 17:07:06 +0000 (UTC) Received: by mail-io1-xd41.google.com with SMTP id d17so47643880ios.13 for ; Sat, 14 Sep 2019 10:07:06 -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=3qE0E0wWXwrJCxz6AZk5upyAg46cYk9S6z+xSo/LLOc=; b=MctHhHYPD1374kPYJj1GfOLLSc4qo/qta4J3VlUYBZ0nsday09wG8TBWNjRECILEf0 GpKC3KNEE/63U32aHjmSPGlu1sd6mSzaz+goRx/8baN/BfbHVagtA6wQGBiLieDbEDIp I5jT0C6Aj8nrika4pTaJH6ToVMio6/ni0qY4ngCLr3xkyF8LtFYTc9T0AJa4vK+L2S4s O9VvrHeR/+WiZsitHREn9Tx95udKSz9KJXgByvIZzcriEQOQGHqZs5IHu56DfFpQd2z8 D31gh+s3jkoOpeV2A0uj/Bacx1KhCXlViMuJ4AYjQ4nnmstDZ4XqEpNvx0Dy4iKN2uuc 5A9A== 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=3qE0E0wWXwrJCxz6AZk5upyAg46cYk9S6z+xSo/LLOc=; b=St7ed1HYWpUQtPHSwUsJWEXGc34YiI+zrUtbH7AWYWmfVDFfn3twaXqSnSumkRwPTP QlZW+Ny1igcDy5fVd/1cwvW2bTL90crLT6SkDQcK9FyCQllekwQHhEElpcQq6Q2A4nR5 Ap4ONMDWZ2iLm58tEujZ1GXcKLNaxOynF0pwRX15k8xvOBSIp/d1PZ3FPgaAGKrK33ta gY+hTnMNsTLlQTMPZn9uBMjkEPYwcfR4loUITxYtHvHXy8LQuzGHxUdC3wJ2N+IW87gz GxgO3b0JJ2yxjaijSUfdggDNGVThi0Z9FOWtTOBQR7Z+eR6h5GTq0X522TseBXwHZta+ Z91Q== X-Gm-Message-State: APjAAAVYPraSU52CRSZkLqM+XqDrWdojttPfPP904SNNNDysj3L0tmhp qljQR6+hXAwVACgax5ZC0vBxqynqjvNRR2V73JNpxC/7 X-Google-Smtp-Source: APXvYqxM1qYXro7bjmWeeZ29Z4wpKlC+Eemk7mIXf9Q+nGrlogVdsy2l+1lvlFvIOvb/oS+ZJq1QbPX8mhu+kxhF4CU= X-Received: by 2002:a6b:b445:: with SMTP id d66mr7265353iof.269.1568480825818; Sat, 14 Sep 2019 10:07:05 -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: <20190911172128.18885-1-williamh@gentoo.org> <20190911172128.18885-4-williamh@gentoo.org> <20190911234815.GA21591@whubbs1.dev.av1.gaikai.org> <20190912154634.GB23846@whubbs1.dev.av1.gaikai.org> <88094567-323c-6f6a-a1d9-0c1b77ef53e3@gentoo.org> <6acd490e-6393-62e4-5d07-71c2a3624417@gentoo.org> <98f7c838-6562-1214-c883-ec4cdbd45d4e@gentoo.org> <20190913211930.088d5513@katipo2.lan> <74ae34f0-75c5-2416-a09f-9551f18ef321@gentoo.org> <20190913131743.11a1d990@patrickm.gaikai.org> <2b8d7f00-fdf9-e879-5035-cc00b9c2b551@gentoo.org> In-Reply-To: <2b8d7f00-fdf9-e879-5035-cc00b9c2b551@gentoo.org> From: Alec Warner Date: Sat, 14 Sep 2019 10:06:54 -0700 Message-ID: Subject: Re: [gentoo-dev] [PATCH 3/3] dev-vcs/hub: migrate to go-module.eclass To: Gentoo Dev Content-Type: multipart/alternative; boundary="00000000000075db3405928666e2" X-Archives-Salt: 54603052-7f2c-4ad6-9b98-f6012cb87fe6 X-Archives-Hash: d16f8db4318574243fcecb1512d175ac --00000000000075db3405928666e2 Content-Type: text/plain; charset="UTF-8" On Fri, Sep 13, 2019 at 4:45 PM Michael Orlitzky wrote: > (Replying to both messages at once.) > > > On 9/13/19 4:17 PM, Patrick McLean wrote: > >> > > I don't think anyone here has suggested that any go packages are > > installed in the stage3 tarballs, or included in profiles. Something's > > presence in the tree does not mean that you are required to install it. > > A package's presence in the tree really has little to zero effect on > > any user that does not use the package. If you do not install the > > package, it will have zero effect on your banking. > > This is true only so far as they never become dependencies of anything > else. Do all new developers know that dev-go is an insecure ghetto? Do > our users? Or might someone accidentally install or depend upon > something in dev-go before learning that crucial bit of information? > > > > I also want to point out that the Gentoo packages for Firefox, > > Chromium, and Webkit all have a _lot_ of bundled dependencies and > > absolutely do static linking internally. If you are using a browser to > > do your banking, you are almost certainly using static linking, even > > without the presence of code written in golang. > > Is this is a "two wrongs make a right" argument? I'm telling mom =P > > > > Despite your (and my) objections to it's approach to linking, golang is > > a very popular language these days with some very popular packages > > written in it. > > No it's not. It's below Delphi and Object Pascal on TIOBE this month. > It's a trend that a tiny percentage of people jumped on because they > heard the name "Google" back when Google was cool. > > The "people want this in Gentoo" argument I understand, but people don't > really have it "in Gentoo." They have a thin wrapper around the "go" > command. They don't get the Gentoo security guarantees, they don't get > the Gentoo license handling, they don't get the ease of management that > comes with a Gentoo @world update. They silently get something less than > they're expecting. We would be better off telling people to run "go > whatever" themselves, or by putting this stuff in an overlay where > expectations are clearly defined. > > > While I personally have opinions about static linking (I basically > > completely agree with you that it's a dumb idea). That said, this has > > nothing to do with this particular discussion, I suggest you take it up > > with the golang upstream. I don't think anyone here is arguing that > > static linking is a great idea and everyone should do it. > > We just have a philosophical difference here. I don't think we should > commit admittedly-dumb ideas to ::gentoo. These packages would work fine > in an overlay until such a time as someone is interested in doing things > correctly. They also work "fine" if you install them with "go" yourself: > Portage isn't doing much for you when everything is bundled, statically > linked, and has LICENSE set incorrectly. > > I don't want to keep replying to these threads -- I've said everything > that I've got to say, and I'm boring myself, so I can only imagine how > you all feel. This will get pushed through anyway, because it always > does. It's just demoralizing constantly begging people not to make > things worse and being ignored. So I think there are really two sorts of issues here. - We discuss things on the mailing list in order to learn more about the problem space. William got feedback on his eclasses, we discovered dynamic go binaries exist, but they are probably not a good idea to use, and I think we have a solution to the LICENSE problem based on some tooling william is also looking into. - There appears to be some expectation that consensus is required on the ML; this has (IMHO) never been true. The 'decider' for what to do isn't the mailing list (by GLEP, it's the council). So this idea that you can object on the ML and stop a thing isn't really something I'd be counting on. Sometimes you convince the OP, and sometimes you don't. I don't think you need to walk away sad when the latter happens. -A --00000000000075db3405928666e2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Fri, Sep 13, 2019 at 4:45 PM Michael O= rlitzky <mjo@gentoo.= org> wrote:
(Replying to both messages at once.)


On 9/13/19 4:17 PM, Patrick McLean wrote:
>>
> I don't think anyone here has suggested that any go packages are > installed in the stage3 tarballs, or included in profiles. Something&#= 39;s
> presence in the tree does not mean that you are required to install it= .
> A package's presence in the tree really has little to zero effect = on
> any user that does not use the package. If you do not install the
> package, it will have zero effect on your banking.

This is true only so far as they never become dependencies of anything
else. Do all new developers know that dev-go is an insecure ghetto? Do
our users? Or might someone accidentally install or depend upon
something in dev-go before learning that crucial bit of information?


> I also want to point out that the Gentoo packages for Firefox,
> Chromium, and Webkit all have a _lot_ of bundled dependencies and
> absolutely do static linking internally. If you are using a browser to=
> do your banking, you are almost certainly using static linking, even > without the presence of code written in golang.

Is this is a "two wrongs make a right" argument? I'm telling = mom =3DP


> Despite your (and my) objections to it's approach to linking, gola= ng is
> a very popular language these days with some very popular packages
> written in it.

No it's not. It's below Delphi and Object Pascal on TIOBE this mont= h.
It's a trend that a tiny percentage of people jumped on because they heard the name "Google" back when Google was cool.

The "people want this in Gentoo" argument I understand, but peopl= e don't
really have it "in Gentoo." They have a thin wrapper around the &= quot;go"
command. They don't get the Gentoo security guarantees, they don't = get
the Gentoo license handling, they don't get the ease of management that=
comes with a Gentoo @world update. They silently get something less than they're expecting. We would be better off telling people to run "g= o
whatever" themselves, or by putting this stuff in an overlay where
expectations are clearly defined.

> While I personally have opinions about static linking (I basically
> completely agree with you that it's a dumb idea). That said, this = has
> nothing to do with this particular discussion, I suggest you take it u= p
> with the golang upstream. I don't think anyone here is arguing tha= t
> static linking is a great idea and everyone should do it.

We just have a philosophical difference here. I don't think we should commit admittedly-dumb ideas to ::gentoo. These packages would work fine in an overlay until such a time as someone is interested in doing things correctly. They also work "fine" if you install them with "g= o" yourself:
Portage isn't doing much for you when everything is bundled, statically=
linked, and has LICENSE set incorrectly.

I don't want to keep replying to these threads -- I've said everyth= ing
that I've got to say, and I'm boring myself, so I can only imagine = how
you all feel. This will get pushed through anyway, because it always
does. It's just demoralizing constantly begging people not to make
things worse and being ignored.

So I think = there are really two sorts of issues here.

=C2=A0-= We discuss things on the mailing list in order to learn more about the pro= blem space. William got feedback on his eclasses, we discovered dynamic go = binaries exist, but they are probably not a good idea to use, and I think w= e have a solution to the LICENSE problem based on some tooling william is a= lso looking into.
=C2=A0- There appears to be some expectation th= at consensus is required on the ML; this has (IMHO) never been true. The &#= 39;decider' for what to do isn't the mailing list (by GLEP, it'= s the council). So this idea that you can object on the ML and stop a thing= isn't really something I'd be counting on. Sometimes you convince = the OP, and sometimes you don't. I don't think you need to walk awa= y sad when the latter happens.

-A=C2=A0
--00000000000075db3405928666e2--