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