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 226D3138334 for ; Thu, 12 Sep 2019 16:42:24 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 24864E096C; Thu, 12 Sep 2019 16:42:19 +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 8941FE0958 for ; Thu, 12 Sep 2019 16:42:18 +0000 (UTC) Received: by mail-io1-xd41.google.com with SMTP id n197so56343816iod.9 for ; Thu, 12 Sep 2019 09:42:18 -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=6MGVb5b2nnkzUIHdcYPFlzDdvXujbHcQP5tmVN/B84U=; b=C+x5EkfdYbQao/Fy0JPRrvYek66LUMOToUS5Fs7zBWSboi6pdBgfM0XLSLUK/DLyuu dVTIc56U19YCY3TWmZyJ10lN38/vZH3tGxdtPWOxc1yCUPJOZXUcUWmRsWVT8eGRyZRp zaQ2r/f2kq80qpMuuwrBXrT30Z+5ejPiZ2lcmSn9IbI+1sKxAxnOHLaZVM/8MaCQYojc ahlIg723OJYnayv/QcP5XDN25sRZ1VMOILQpBeocKTXIxv5uOFROEqMauZohpg0cVITK fvrAXO4Mu2UaKuQVpMI6Bz5IQZN9OLGIoHA2ZdfQPxr7L2TTaXyauFEbbd6iGdwr/YID 5A6Q== 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=6MGVb5b2nnkzUIHdcYPFlzDdvXujbHcQP5tmVN/B84U=; b=VvES++XC/WxiXkBTQcsA9CbEHxxw2TQA3C4CTW6qi5yA/UfgBUHoFXOhX/w8By29cb IGwYwqzFP6/eUZD5jjCZpqs5xiH5RylImyoKeeihb5Y/R/srl7NxZG5O9VcA8WmbuNuQ blcEaQa7SlEToWC4JvxPTBPOEr63rv98vVgefJ9oxNPLEU9ySYZJVw+zAl/Iv9HCurJe LXPj+KYRiXpQpCyj+wepkyPI/ze49fcOxHYnb4jDX4HGcXzbKyod1LXyOFveiaOeyX0T oIWo/UL0+gtZVuw/+Tt9kfQfh3d2vk4S0CPJuuJZrfDYCkA50AIbjcu5HU5sFLbXNhBh Kh9g== X-Gm-Message-State: APjAAAXNfR4Bn9eCJqW6OoRS05f/f4K9er+C2cO4UotZUqHtFGx8NXAd YOFvRwoc1Hwz7B6GAo+RiK6nL4qUvqXz/osR42MZrcIP X-Google-Smtp-Source: APXvYqwXqucGvcRlHXM74K18bHnEFLAolIE86/2gxPTxMSHp6YEa3lVv+Il5y1PXZHTOfVb4df+iTuCTubgxpHFSXOo= X-Received: by 2002:a05:6602:cb:: with SMTP id z11mr5707374ioe.4.1568306537101; Thu, 12 Sep 2019 09:42:17 -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> In-Reply-To: <88094567-323c-6f6a-a1d9-0c1b77ef53e3@gentoo.org> From: Alec Warner Date: Thu, 12 Sep 2019 09:42:05 -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="0000000000000b0e3905925dd23b" X-Archives-Salt: a661c07d-17fd-4d94-b719-f5294cced250 X-Archives-Hash: f0345fe686aed587c8dbda20e038a2c1 --0000000000000b0e3905925dd23b Content-Type: text/plain; charset="UTF-8" On Thu, Sep 12, 2019 at 9:14 AM Michael Orlitzky wrote: > On 9/12/19 11:46 AM, William Hubbs wrote: > > > > In other words, the way I see this is a tree-wide issue. LICENSE= for > > any package should list every license for every package it links to or > > uses. > > > There is no issue tree-wide, because no one else is trying to cut > corners and bundle every dependency of every package. All of our > dependencies are in separate packages, with separate LICENSE variables. > So when you install one package, the LICENSE variables of all its > dependencies pulled in by the package manager are indeed taken into > account. That's the whole point of a package manager -- it can do these > things for you if the developers do their jobs and package software > correctly. > I'm not really keen on this language ("cutting corners"). Newer languages are not C, they don't act like C, build like C or do many other things like C[0]. That presents engineering challenges to Gentoo; because the standard way of doing stuff doesn't work. I nominally see two avenues here: (1) go ebuilds with modules put the modules in DEPEND, every module is a package, we have some kind of tooling to essentially handle the creation of these packages (and by package I mean some kind of Gentoo compatible package, including the tarballs, checksums, LICENSE, and so forth.) Then during src_prepare() we essentially do the work necessary to place these package sources in the right place (e.g. wherever the module system expects them.) (2) Is Williamh's current implementation, developers themselves run go mod, get all the modules, package them up, and distribute them. The tooling for this should handle LICENSE. One immediate problem I see with (1) is that these modules often don't have releases like traditional packages do, so you end up with a dependency on (somemodulename, ). This then leads to a version explosion as every go package (N) depends on a different SHA1HASH of module M; it ends up being a bit of a hot mess. This may cause some complexities (it bloats the depgraph for one) and so William's approach simplifies the problem. In general I don't see bundling as a major problem. In the land of dynamic binaries, it's a big advantage because you can upgrade libfoo and all consumers of libfoo get the upgrade upon process restart. This isn't true for most go programs which are statically linked; so you end up asking yourself "why should I make a package for every go module?" One obvious answer is that portage then tracks what packages are consuming a given module and you can plausibly write a tool that does things like "moduleX has a security update, please recompile all packages that DEPEND on moduleX" which seems like a tool people would want. [0] I feel like this is a common idea in Gentoo throughout. Anything new is bad. Anything that violates norms is bad. Anything that violates the model we have been using for 20 years is bad. I wish people were more open to have a discussion without crapping on new ideas quite so thoroughly. -A --0000000000000b0e3905925dd23b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Thu, Sep 12, 2019 at 9:14 AM Michael O= rlitzky <mjo@gentoo.org> wrote:=
On 9/12/19 11:46 AM, William Hubbs wrote:
>
> In other words, the way I see this is a tree-wide issue. LICENSE=3D fo= r
> any package should list every license for every package it links to or=
> uses.
>
There is no issue tree-wide, because no one else is trying to cut
corners and bundle every dependency of every package. All of our
dependencies are in separate packages, with separate LICENSE variables.
So when you install one package, the LICENSE variables of all its
dependencies pulled in by the package manager are indeed taken into
account. That's the whole point of a package manager -- it can do these=
things for you if the developers do their jobs and package software
correctly.

I'm not really keen on t= his language ("cutting corners"). Newer languages are not C, they= don't act like C, build like C or do many other things like C[0]. That= presents engineering challenges to Gentoo; because the standard way of doi= ng stuff doesn't work. I nominally see two avenues here:

=
(1) go ebuilds with modules put the modules in DEPEND, every mod= ule is a package, we have some kind of tooling to essentially handle the cr= eation of these packages (and by package I mean some kind of Gentoo compati= ble package, including the tarballs, checksums, LICENSE, and so forth.) The= n during src_prepare() we essentially do the work necessary to place these = package sources in the right place (e.g. wherever the module system expects= them.)

(2) Is Williamh's current implementati= on, developers themselves run go mod, get all the modules, package them up,= and distribute them. The tooling for this should handle LICENSE.

One immediate problem I see with (1) is that these modules = often don't have releases like traditional packages do, so you end up w= ith a dependency on (somemodulename, <SHA1HASH>). This then leads to = a version explosion as every go package (N) depends on a different SHA1HASH= of module M; it ends up being a bit of a hot mess. This may cause some com= plexities (it bloats the depgraph for one) and so William's approach si= mplifies the problem.

In general I don't see b= undling as a major problem. In the land of dynamic binaries, it's a big= advantage because you can upgrade libfoo and all consumers of libfoo get t= he upgrade upon process restart. This isn't true for most go programs w= hich are statically linked; so you end up asking yourself "why should = I make a package for every go module?" One obvious answer is that port= age then tracks what packages are consuming a given module and you can plau= sibly write a tool that does things like "moduleX has a security updat= e, please recompile all packages that DEPEND on moduleX" which seems l= ike a tool people would want.

[0] I feel like this= is a common idea in Gentoo throughout. Anything new is bad. Anything that = violates=C2=A0norms is bad. Anything that violates the model we have been u= sing for 20 years is bad. I wish people were more open to have a discussion= without crapping on new ideas quite so thoroughly.

-A
--0000000000000b0e3905925dd23b--