1 |
On Tue, Jun 30, 2015 at 10:53:58AM -0700, Zac Medico wrote: |
2 |
> On 06/30/2015 08:35 AM, William Hubbs wrote: |
3 |
> > All, |
4 |
> > |
5 |
> > we have digressed a bit, so I want to bring the discussion back to what |
6 |
> > my main concerns are about this issue. |
7 |
> > |
8 |
> > 1. Should we bundle Go packages with Go software? |
9 |
> > |
10 |
> > If we do, except for the Go standard library which is part of |
11 |
> > dev-lang/go, do we need to bother with installing Go sources and |
12 |
> > packages at all? |
13 |
> > |
14 |
> > The down side of the whole bundling idea is that every consumer |
15 |
> > on someone's system could potentially have a different version of the |
16 |
> > Go package, which doesn't lend itself well to security concerns. |
17 |
> > |
18 |
> > This is why bundling is generally discouraged in Gentoo. |
19 |
> |
20 |
> Yes, as a general rule, bundling is sub-optimal. However, there are |
21 |
> often exceptions to general rules like these, especially when there are |
22 |
> competing concerns to contend with. |
23 |
|
24 |
I don't really see what the competing concerns are in this case. |
25 |
|
26 |
> > Also, if we bundle, most of dev-go/* doesn't need to exist because these |
27 |
> > libraries would be bundled into and statically linked into the software |
28 |
> > that needs them. |
29 |
> |
30 |
> Some static libraries are commonly used enough that it might be |
31 |
> reasonable to install them. Alternatively, we might invent a notion of |
32 |
> having one ebuild execute another ebuild in order to install static |
33 |
> dependencies into a temporary build directory. |
34 |
|
35 |
Why do we need to worry about how many projects use a library? Upstream |
36 |
has it as a library for good reason, so that multiple projects can use |
37 |
it. If upstream installs it as a library, that's how we should install |
38 |
it if we install it. |
39 |
|
40 |
The problem I see with the argument about "commonly used enough" is the |
41 |
vagueness of it. If we have two packages that use a library, it is |
42 |
commonly used enough that it should be installed separately. |
43 |
|
44 |
If we start out bundling libraries, especially libraries from different |
45 |
upstreams than the package we are working on, that forces all go |
46 |
maintainers to check all go ebuilds in the tree to see if multiple |
47 |
bundling is going on and open bugs to create separate ebuilds for |
48 |
libraries that were only used before by one package but now are used by |
49 |
more than one. |
50 |
|
51 |
> > 2. How should we bundle? |
52 |
> > |
53 |
> > This is where my concern about consul and some other ebuilds comes in. |
54 |
> > |
55 |
> > The way the consul ebuild is written (putting the commit hashes of |
56 |
> > dependencies in SRC_URI) assumes that all of the dependencies will stay |
57 |
> > on github. This makes the ebuild far less flexable than go itself is. |
58 |
> |
59 |
> Agreed. However, there's no rule which says that we have to force all |
60 |
> ebuilds to fit into common templates. |
61 |
|
62 |
We do when they deal with common issues; that's the whole point of |
63 |
language-based eclasses, e.g. ruby* perl* and python*. |
64 |
|
65 |
> > If we are going to bundle, I would rather have one tarball that includes |
66 |
> > all of the sources for consul and the dependent libraries dropped on the |
67 |
> > Gentoo mirrors. Such a tarball is very easy to create. |
68 |
> |
69 |
> I would prefer to use separate tarballs for each dependency, preferably |
70 |
> with the commit hash encoded in the tarball name. This makes the ebuild |
71 |
> dependencies transparent in the sense that the commit hashes of the |
72 |
> dependencies are readily available. The "one big tarball" is opaque |
73 |
> rather than transparent, and it will have a tendency bloat the mirrors. |
74 |
> By keeping the dependencies in separate tarballs, we can easily do a |
75 |
> revbump that updates a subset of the dependencies, without having to |
76 |
> re-pack everything into a big bloated tarball. |
77 |
|
78 |
I can agree with part of this; one big tarball is less transparent than |
79 |
multiple tarballs. |
80 |
|
81 |
Another thing to consider is, with one big tarball, you can name the |
82 |
extraction directory to match ${S}, which means there would be no need |
83 |
for magic in the ebuilds to deal with putting extracted directories in |
84 |
the right place. |
85 |
|
86 |
All I'm saying is, if we are going to bundle, lets go all in and not |
87 |
download multiple upstream packages in src_uri but put them in big |
88 |
tarballs. |
89 |
|
90 |
If we are not going to bundle, the best way to handle it is to not |
91 |
bundle at all imo. |
92 |
|
93 |
William |