1 |
On Fri, Sep 13, 2019 at 4:45 PM Michael Orlitzky <mjo@g.o> wrote: |
2 |
|
3 |
> (Replying to both messages at once.) |
4 |
> |
5 |
> |
6 |
> On 9/13/19 4:17 PM, Patrick McLean wrote: |
7 |
> >> |
8 |
> > I don't think anyone here has suggested that any go packages are |
9 |
> > installed in the stage3 tarballs, or included in profiles. Something's |
10 |
> > presence in the tree does not mean that you are required to install it. |
11 |
> > A package's presence in the tree really has little to zero effect on |
12 |
> > any user that does not use the package. If you do not install the |
13 |
> > package, it will have zero effect on your banking. |
14 |
> |
15 |
> This is true only so far as they never become dependencies of anything |
16 |
> else. Do all new developers know that dev-go is an insecure ghetto? Do |
17 |
> our users? Or might someone accidentally install or depend upon |
18 |
> something in dev-go before learning that crucial bit of information? |
19 |
> |
20 |
|
21 |
> |
22 |
> > I also want to point out that the Gentoo packages for Firefox, |
23 |
> > Chromium, and Webkit all have a _lot_ of bundled dependencies and |
24 |
> > absolutely do static linking internally. If you are using a browser to |
25 |
> > do your banking, you are almost certainly using static linking, even |
26 |
> > without the presence of code written in golang. |
27 |
> |
28 |
> Is this is a "two wrongs make a right" argument? I'm telling mom =P |
29 |
> |
30 |
> |
31 |
> > Despite your (and my) objections to it's approach to linking, golang is |
32 |
> > a very popular language these days with some very popular packages |
33 |
> > written in it. |
34 |
> |
35 |
> No it's not. It's below Delphi and Object Pascal on TIOBE this month. |
36 |
> It's a trend that a tiny percentage of people jumped on because they |
37 |
> heard the name "Google" back when Google was cool. |
38 |
> |
39 |
|
40 |
> The "people want this in Gentoo" argument I understand, but people don't |
41 |
> really have it "in Gentoo." They have a thin wrapper around the "go" |
42 |
> command. They don't get the Gentoo security guarantees, they don't get |
43 |
> the Gentoo license handling, they don't get the ease of management that |
44 |
> comes with a Gentoo @world update. They silently get something less than |
45 |
> they're expecting. We would be better off telling people to run "go |
46 |
> whatever" themselves, or by putting this stuff in an overlay where |
47 |
> expectations are clearly defined. |
48 |
> |
49 |
|
50 |
> > While I personally have opinions about static linking (I basically |
51 |
> > completely agree with you that it's a dumb idea). That said, this has |
52 |
> > nothing to do with this particular discussion, I suggest you take it up |
53 |
> > with the golang upstream. I don't think anyone here is arguing that |
54 |
> > static linking is a great idea and everyone should do it. |
55 |
> |
56 |
> We just have a philosophical difference here. I don't think we should |
57 |
> commit admittedly-dumb ideas to ::gentoo. These packages would work fine |
58 |
> in an overlay until such a time as someone is interested in doing things |
59 |
> correctly. They also work "fine" if you install them with "go" yourself: |
60 |
> Portage isn't doing much for you when everything is bundled, statically |
61 |
> linked, and has LICENSE set incorrectly. |
62 |
> |
63 |
|
64 |
> I don't want to keep replying to these threads -- I've said everything |
65 |
> that I've got to say, and I'm boring myself, so I can only imagine how |
66 |
> you all feel. This will get pushed through anyway, because it always |
67 |
> does. It's just demoralizing constantly begging people not to make |
68 |
> things worse and being ignored. |
69 |
|
70 |
|
71 |
So I think there are really two sorts of issues here. |
72 |
|
73 |
- We discuss things on the mailing list in order to learn more about the |
74 |
problem space. William got feedback on his eclasses, we discovered dynamic |
75 |
go binaries exist, but they are probably not a good idea to use, and I |
76 |
think we have a solution to the LICENSE problem based on some tooling |
77 |
william is also looking into. |
78 |
- There appears to be some expectation that consensus is required on the |
79 |
ML; this has (IMHO) never been true. The 'decider' for what to do isn't the |
80 |
mailing list (by GLEP, it's the council). So this idea that you can object |
81 |
on the ML and stop a thing isn't really something I'd be counting on. |
82 |
Sometimes you convince the OP, and sometimes you don't. I don't think you |
83 |
need to walk away sad when the latter happens. |
84 |
|
85 |
-A |