Re: [gentoo-dev] git checkout in ebuild?

[Damo Brisbane]

The git.r3 eclass method seems good practice for a specific commit. I'll
have a look at the snap site today (AEST) - see if I can find a tarball -
this seems preferable to commit.Thanks for the very helpful replies;

On Tue, Oct 17, 2017 at 8:04 AM, Kent Fredric <kentnl@g.o> wrote:

> On Mon, 16 Oct 2017 13:31:53 +1000
> Damo Brisbane <dhatchett2@×××××.com> wrote:
>
> > Hello,
> >
> > I am wanting to make an ebuild for Intel's (Apache 2 licensed) snap
> > monitoring framework (https://github.com/intelsdi-x/snap). It seems the
> > current version (2.0.0) does not compile the golang binaries with some
> type
> > of recent grpc API incompatibility. I can successfully compile by going:
> >
> > go get ...
> > cd <SRC_DIR>
> > git checkout 1.3.0
> > make all
> >
> > This gets me the binaries (snaptel, snapteld); does anyone know if I can
> > put this process (git checkout..) into an .ebuild file (or some other
> > suggestion)?
> >
> > Cheers,
>
> emerge -va app-portage/eclass-manpages
> man 5 git-r3.eclass
>
> -> ECLASS_VARIABLES
>
> Look at almost any ebuild in tree using git-r3.eclass with a -9999
> version for examples of how you can use this if the eclass
> documentation isn't clear enough.
>
> But, these are forbidden in gentoo as a normal package.
>
> Typically, the solution there is finding a tarball, or producing
> a snapshot of the tree and publishing it somewhere.
>
> There's writing on that here:
>
> https://devmanual.gentoo.org/ebuild-writing/functions/src_
> unpack/svn-sources/index.html
>
> and
>
> https://devmanual.gentoo.org/ebuild-writing/functions/src_
> unpack/cvs-sources/index.html
>
> But there's no specific reference for Git sources, although the general
> rules and concepts still apply.
>
> Other commenters have mentioned using github tagged release's for
> tarballs, but even those aren't necessarily great, because:
>
> - Historically, the tarball's SHA1 can change due to github's tooling
> changing
> - Tags are not in any way immutable, and its been seen that people
>   forcibly replace tags in order to keep their git history tidy.
>   ( Which doesn't change the functional source code, bug can be
>   sufficient to change timestamps in the tarball, and thus, the SHA1 )
>
>