Re: [gentoo-dev] rfc: Go ebuilds bundling multiple upstream sources

[Zac Medico]

On 06/30/2015 08:35 AM, William Hubbs wrote:
> All,
>
> we have digressed a bit, so I want to bring the discussion back to what
> my main concerns are about this issue.
>
> 1. Should we bundle Go packages with Go software?
>
> If we do, except for the Go standard library which is part of
> dev-lang/go, do we need to bother with installing Go sources and
> packages at all?
>
> The down side of the whole bundling idea is that every consumer
> on someone's system could potentially have a different version of the
> Go package, which doesn't lend itself well to security concerns.
>
> This is why bundling is generally discouraged in Gentoo.

Yes, as a general rule, bundling is sub-optimal. However, there are
often exceptions to general rules like these, especially when there are
competing concerns to contend with.

> Also, if we bundle, most of dev-go/* doesn't need to exist because these
> libraries would be bundled into and statically linked into the software
> that needs them.

Some static libraries are commonly used enough that it might be
reasonable to install them. Alternatively, we might invent a notion of
having one ebuild execute another ebuild in order to install static
dependencies into a temporary build directory.

> 2. How should we bundle?
>
> This is where my concern about consul and some other ebuilds comes in.
>
> The way the consul ebuild is written (putting the commit hashes of
> dependencies in SRC_URI) assumes that all of the dependencies will stay
> on github. This makes the ebuild far less flexable than go itself is.

Agreed. However, there's no rule which says that we have to force all
ebuilds to fit into common templates.

> If we are going to bundle, I would rather have one tarball that includes
> all of the sources for consul and the dependent libraries dropped on the
> Gentoo mirrors. Such a tarball is very easy to create.

I would prefer to use separate tarballs for each dependency, preferably
with the commit hash encoded in the tarball name. This makes the ebuild
dependencies transparent in the sense that the commit hashes of the
dependencies are readily available. The "one big tarball" is opaque
rather than transparent, and it will have a tendency bloat the mirrors.
By keeping the dependencies in separate tarballs, we can easily do a
revbump that updates a subset of the dependencies, without having to
re-pack everything into a big bloated tarball.
-- 
Thanks,
Zac