Re: [gentoo-dev] [PATCH 3/3] dev-vcs/hub: migrate to go-module.eclass

[Alec Warner]

On Thu, Sep 12, 2019 at 9:14 AM Michael Orlitzky <mjo@g.o> 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, <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 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