1 |
Mike Auty posted on Sun, 11 Mar 2018 19:19:00 +0000 as excerpted: |
2 |
|
3 |
> tldr; Github will tarball up specific commits (or master) for you to add |
4 |
> to SRC_URI. |
5 |
> |
6 |
> I ended up using the github API to pull down a tarball of the git repo, |
7 |
> rather than using git to pull it down. I suppose that offers the |
8 |
> ability to Manifest it and check for changes, but I now have to encode |
9 |
> the fixed commit into every version of the ebuild because the only |
10 |
> location it's recorded is in the submodule commit hash of the package's |
11 |
> repo. |
12 |
|
13 |
Please check... |
14 |
|
15 |
If I'm recalling correctly a warning posted on this list, repeated calls |
16 |
to the github tarballing API for the same commit will result in delivery |
17 |
of tarballs with differing checksums. How/why wasn't explained as I |
18 |
recall, possibly part of the reason I'm not sure I'm recalling things |
19 |
correctly as that would have internally flagged it as unreliable/needing- |
20 |
verification, but that was the warning as I remember it. |
21 |
|
22 |
If it's correct, you can pull the tarball from github to store on devspace |
23 |
and link it as the checksummed tarball, as that's static and won't |
24 |
change, but you can't link the github tarballing API directly, as that |
25 |
/will/ change and thus will fail sources checksum verification at least |
26 |
some of the time. |
27 |
|
28 |
But (assuming avoiding linking devspace is worth the trouble in the first |
29 |
place if possible) either verify it yourself or wait for verification/ |
30 |
negation from others, as I'm not entirely sure I'm recalling that warning |
31 |
post correctly. It might have been for other than github, or I might |
32 |
have misunderstood, or maybe they've fixed that problem by now, or... |
33 |
|
34 |
-- |
35 |
Duncan - List replies preferred. No HTML msgs. |
36 |
"Every nonfree program has a lord, a master -- |
37 |
and if you use the program, he is your master." Richard Stallman |