1 |
On 06/30/2015 01:30 PM, William Hubbs wrote: |
2 |
> On Tue, Jun 30, 2015 at 10:53:58AM -0700, Zac Medico wrote: |
3 |
>> On 06/30/2015 08:35 AM, William Hubbs wrote: |
4 |
>>> All, |
5 |
>>> |
6 |
>>> we have digressed a bit, so I want to bring the discussion back to what |
7 |
>>> my main concerns are about this issue. |
8 |
>>> |
9 |
>>> 1. Should we bundle Go packages with Go software? |
10 |
>>> |
11 |
>>> If we do, except for the Go standard library which is part of |
12 |
>>> dev-lang/go, do we need to bother with installing Go sources and |
13 |
>>> packages at all? |
14 |
>>> |
15 |
>>> The down side of the whole bundling idea is that every consumer |
16 |
>>> on someone's system could potentially have a different version of the |
17 |
>>> Go package, which doesn't lend itself well to security concerns. |
18 |
>>> |
19 |
>>> This is why bundling is generally discouraged in Gentoo. |
20 |
>> |
21 |
>> Yes, as a general rule, bundling is sub-optimal. However, there are |
22 |
>> often exceptions to general rules like these, especially when there are |
23 |
>> competing concerns to contend with. |
24 |
> |
25 |
> I don't really see what the competing concerns are in this case. |
26 |
|
27 |
The competing concern is that un-bundling has some possibly undesirable |
28 |
consequences, mainly that it means we'll be installing static libraries |
29 |
that were only intended to be temporary build artifacts. It makes sense |
30 |
to install them if there are multiple consumers, otherwise it doesn't |
31 |
make much sense. |
32 |
|
33 |
>>> Also, if we bundle, most of dev-go/* doesn't need to exist because these |
34 |
>>> libraries would be bundled into and statically linked into the software |
35 |
>>> that needs them. |
36 |
>> |
37 |
>> Some static libraries are commonly used enough that it might be |
38 |
>> reasonable to install them. Alternatively, we might invent a notion of |
39 |
>> having one ebuild execute another ebuild in order to install static |
40 |
>> dependencies into a temporary build directory. |
41 |
> |
42 |
> Why do we need to worry about how many projects use a library? |
43 |
|
44 |
If you want to clutter the tree with trivial ebuilds that only have a |
45 |
single consumer, then I guess that's fine. It's not clear to me that |
46 |
this is the best course of action, but I'm not going to try to stop you |
47 |
if that's what you want to do. |
48 |
|
49 |
> Upstream |
50 |
> has it as a library for good reason, so that multiple projects can use |
51 |
> it. If upstream installs it as a library, that's how we should install |
52 |
> it if we install it. |
53 |
|
54 |
I don't think that consul upstream "installs it as a library." The last |
55 |
time that I checked upstream's "build from source" instructions, the |
56 |
consul binary was the only result of interest, so all of the temporary |
57 |
build artifacts could simply be discarded after the consul binary had |
58 |
been built. |
59 |
|
60 |
> The problem I see with the argument about "commonly used enough" is the |
61 |
> vagueness of it. If we have two packages that use a library, it is |
62 |
> commonly used enough that it should be installed separately. |
63 |
|
64 |
As soon as you have at least two consumers, then you have a good reason |
65 |
to un-bundle a library. If there's only one consumer, then un-bundling |
66 |
becomes questionable. |
67 |
|
68 |
> If we start out bundling libraries, especially libraries from different |
69 |
> upstreams than the package we are working on, that forces all go |
70 |
> maintainers to check all go ebuilds in the tree to see if multiple |
71 |
> bundling is going on and open bugs to create separate ebuilds for |
72 |
> libraries that were only used before by one package but now are used by |
73 |
> more than one. |
74 |
|
75 |
Nobody is being forced to do anything. If a maintainer of a Go package |
76 |
than bundles libraries is doing a version bump, then it would be a good |
77 |
time for him to check if ebuilds have been created for any of those |
78 |
bundled dependencies, and un-bundle them at that point. |
79 |
|
80 |
>>> 2. How should we bundle? |
81 |
>>> |
82 |
>>> This is where my concern about consul and some other ebuilds comes in. |
83 |
>>> |
84 |
>>> The way the consul ebuild is written (putting the commit hashes of |
85 |
>>> dependencies in SRC_URI) assumes that all of the dependencies will stay |
86 |
>>> on github. This makes the ebuild far less flexable than go itself is. |
87 |
>> |
88 |
>> Agreed. However, there's no rule which says that we have to force all |
89 |
>> ebuilds to fit into common templates. |
90 |
> |
91 |
> We do when they deal with common issues; that's the whole point of |
92 |
> language-based eclasses, e.g. ruby* perl* and python*. |
93 |
|
94 |
There can always be outliers that don't fit your existing templates. |
95 |
|
96 |
>>> If we are going to bundle, I would rather have one tarball that includes |
97 |
>>> all of the sources for consul and the dependent libraries dropped on the |
98 |
>>> Gentoo mirrors. Such a tarball is very easy to create. |
99 |
>> |
100 |
>> I would prefer to use separate tarballs for each dependency, preferably |
101 |
>> with the commit hash encoded in the tarball name. This makes the ebuild |
102 |
>> dependencies transparent in the sense that the commit hashes of the |
103 |
>> dependencies are readily available. The "one big tarball" is opaque |
104 |
>> rather than transparent, and it will have a tendency bloat the mirrors. |
105 |
>> By keeping the dependencies in separate tarballs, we can easily do a |
106 |
>> revbump that updates a subset of the dependencies, without having to |
107 |
>> re-pack everything into a big bloated tarball. |
108 |
> |
109 |
> I can agree with part of this; one big tarball is less transparent than |
110 |
> multiple tarballs. |
111 |
> |
112 |
> Another thing to consider is, with one big tarball, you can name the |
113 |
> extraction directory to match ${S}, which means there would be no need |
114 |
> for magic in the ebuilds to deal with putting extracted directories in |
115 |
> the right place. |
116 |
|
117 |
I think this so-called "magic" is a small price to pay for transparency, |
118 |
and the ease with which one can do a revision bump while updating a |
119 |
subset of the bundled dependencies (all the tarballs are automatically |
120 |
generated by github, so I don't have to pack any of them myself). |
121 |
|
122 |
> All I'm saying is, if we are going to bundle, lets go all in and not |
123 |
> download multiple upstream packages in src_uri but put them in big |
124 |
> tarballs. |
125 |
|
126 |
I would prefer to create separate ebuilds for all of the dependencies, |
127 |
than be forced to do this. |
128 |
|
129 |
> If we are not going to bundle, the best way to handle it is to not |
130 |
> bundle at all imo. |
131 |
|
132 |
Even if there is only a single consumer of said libraries? |
133 |
-- |
134 |
Thanks, |
135 |
Zac |