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 <ken...@gentoo.org> wrote: > On Mon, 16 Oct 2017 13:31:53 +1000 > Damo Brisbane <dhatche...@gmail.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 ) > >
