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. |