Gentoo Archives: gentoo-dev

From: Michael Orlitzky <mjo@g.o>
To: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] [PATCH 3/3] dev-vcs/hub: migrate to go-module.eclass
Date: Thu, 12 Sep 2019 16:52:38
Message-Id: 6acd490e-6393-62e4-5d07-71c2a3624417@gentoo.org
In Reply to: Re: [gentoo-dev] [PATCH 3/3] dev-vcs/hub: migrate to go-module.eclass by Alec Warner
1 On 9/12/19 12:42 PM, Alec Warner wrote:
2 >
3 > In general I don't see bundling as a major problem. In the land of
4 > dynamic binaries, it's a big advantage because you can upgrade libfoo
5 > and all consumers of libfoo get the upgrade upon process restart. This
6 > isn't true for most go programs which are statically linked; so you end
7 > up asking yourself "why should I make a package for every go module?"
8 > One obvious answer is that portage then tracks what packages are
9 > consuming a given module and you can plausibly write a tool that does
10 > things like "moduleX has a security update, please recompile all
11 > packages that DEPEND on moduleX" which seems like a tool people would want.
12 >
13
14 Subslots do this already. Portage does this already. We have this "tool
15 that people would want," but only if developers can be bothered to
16 package things.
17
18
19 > [0] I feel like this is a common idea in Gentoo throughout. Anything new
20 > is bad. Anything that violates norms is bad. Anything that violates the
21 > model we have been using for 20 years is bad. I wish people were more
22 > open to have a discussion without crapping on new ideas quite so thoroughly.
23
24 This is computer *science*. Some ideas are just wrong, and nothing of
25 value is gained by trying not to hurt the feelings of the flat-earthers.

Replies