Gentoo Archives: gentoo-dev

From: Patrick McLean <chutzpah@g.o>
To: Michael Orlitzky <mjo@g.o>
Cc: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] [PATCH 3/3] dev-vcs/hub: migrate to go-module.eclass
Date: Sat, 14 Sep 2019 00:22:42
Message-Id: 20190913172230.2d765910@patrickm.gaikai.org
In Reply to: Re: [gentoo-dev] [PATCH 3/3] dev-vcs/hub: migrate to go-module.eclass by Michael Orlitzky
1 On Fri, 13 Sep 2019 19:44:55 -0400
2 Michael Orlitzky <mjo@g.o> wrote:
3
4 > (Replying to both messages at once.)
5 >
6 >
7 > On 9/13/19 4:17 PM, Patrick McLean wrote:
8 > >>
9 > > I don't think anyone here has suggested that any go packages are
10 > > installed in the stage3 tarballs, or included in profiles.
11 > > Something's presence in the tree does not mean that you are
12 > > required to install it. A package's presence in the tree really has
13 > > little to zero effect on any user that does not use the package. If
14 > > you do not install the package, it will have zero effect on your
15 > > banking.
16 >
17 > This is true only so far as they never become dependencies of anything
18 > else. Do all new developers know that dev-go is an insecure ghetto? Do
19 > our users? Or might someone accidentally install or depend upon
20 > something in dev-go before learning that crucial bit of information?
21
22 A suggestion was made on IRC to have a pkg_postinst in the eclass that
23 warn about golang package dependencies not having the same level of
24 Gentoo security coverage that other packages in the tree have due to
25 static linking. I think this is a reasonable approach, and users and
26 developers will know. There is precedent for this, see
27 sys-kernel/vanilla-sources
28
29 > > I also want to point out that the Gentoo packages for Firefox,
30 > > Chromium, and Webkit all have a _lot_ of bundled dependencies and
31 > > absolutely do static linking internally. If you are using a browser
32 > > to do your banking, you are almost certainly using static linking,
33 > > even without the presence of code written in golang.
34 >
35 > Is this is a "two wrongs make a right" argument? I'm telling mom =P
36
37 I am pointing out that we can't ban all static linking in the tree,
38 many upstream packages won't work without it (or significant effort
39 that no one has the time or motivation for).
40
41 > > Despite your (and my) objections to it's approach to linking,
42 > > golang is a very popular language these days with some very popular
43 > > packages written in it.
44 >
45 > No it's not. It's below Delphi and Object Pascal on TIOBE this month.
46 > It's a trend that a tiny percentage of people jumped on because they
47 > heard the name "Google" back when Google was cool.
48
49 Random stats from a website are not really an indication of how much a
50 language is being used. There are plenty of very popular packages that
51 are written in golang.
52
53 > The "people want this in Gentoo" argument I understand, but people
54 > don't really have it "in Gentoo." They have a thin wrapper around the
55 > "go" command. They don't get the Gentoo security guarantees, they
56 > don't get the Gentoo license handling, they don't get the ease of
57 > management that comes with a Gentoo @world update. They silently get
58 > something less than they're expecting. We would be better off telling
59 > people to run "go whatever" themselves, or by putting this stuff in
60 > an overlay where expectations are clearly defined.
61
62 Users and Gentoo developers want Docker and Kubernetes (to name a
63 couple) in the main tree. These are written in golang. I don't think we
64 should ban packages because of the language they are written in.
65 Especially if there are developers who want to maintain them.
66
67 They do get the ease of management of @world in that if the upstream
68 package releases a new version, it will be pulled in via an @world
69 update. That is quite a large advantage to users, and is worth doing if
70 there are developers willing to maintain the packages in the tree.
71
72 >
73 > > While I personally have opinions about static linking (I basically
74 > > completely agree with you that it's a dumb idea). That said, this
75 > > has nothing to do with this particular discussion, I suggest you
76 > > take it up with the golang upstream. I don't think anyone here is
77 > > arguing that static linking is a great idea and everyone should do
78 > > it.
79 >
80 > We just have a philosophical difference here. I don't think we should
81 > commit admittedly-dumb ideas to ::gentoo. These packages would work
82 > fine in an overlay until such a time as someone is interested in
83 > doing things correctly. They also work "fine" if you install them
84 > with "go" yourself: Portage isn't doing much for you when everything
85 > is bundled, statically linked, and has LICENSE set incorrectly.
86
87 When "doing things correctly" means basically forking the entire
88 ecosystem and maintaining all the forks internally, that is not
89 something that is ever going to happen. There is demand from users and
90 developers for golang packages.
91
92 It's the same reason why we don't unbundle everything in Firefox and
93 Chromium, it's simply too much work. It basically means maintaining our
94 own fork of the package. That also means security updates will take
95 significantly longer, as the fork will need to be rebased on the new
96 upstream version.
97
98 > I don't want to keep replying to these threads -- I've said everything
99 > that I've got to say, and I'm boring myself, so I can only imagine how
100 > you all feel. This will get pushed through anyway, because it always
101 > does. It's just demoralizing constantly begging people not to make
102 > things worse and being ignored.
103
104 Then don't, golang and packages written in it are going to stay in the
105 tree and new golang packages are going to be added. This entire
106 thread has been about how we are going to support a newer packaging
107 style upstream adopted.
108
109 I encourage you to package.mask dev-lang/go, and carefully inspect any
110 -bin packages you install to make sure you don't install anything
111 written in golang on your machine.