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