| 1 |
So, |
| 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 |
I could have it live in the PV, but I think that'd lead to potential |
| 14 |
version sorting errors if people try and use copies of the ebuild. |
| 15 |
Making typeshed its own package doesn't help because it's installed |
| 16 |
under /usr/share/mypy/typeshed, not /usr/share/typeshed so it really is |
| 17 |
part of mypy (for now). So I'll see how this goes and listen for |
| 18 |
feedback... |
| 19 |
|
| 20 |
Mike 5:) |
| 21 |
|
| 22 |
On 11/03/18 18:05, Mike Auty wrote: |
| 23 |
> Hiya, |
| 24 |
> |
| 25 |
> I'm trying to update/package up mypy for the main tree which, whilst it |
| 26 |
> provides a release tarball, relies upon a data library (typeshed) which |
| 27 |
> does not provide releases. The recommended method of installation by |
| 28 |
> upstream is to use git submodules (which the ebuild will do happily), |
| 29 |
> but repoman rightly complains about LIVEVCS issues. |
| 30 |
> |
| 31 |
> Is the current recommended method for dealing with this to manually |
| 32 |
> create a tarball and stash it on dev.gentoo.org somewhere accessible or |
| 33 |
> are there updated guidelines for this kind of scenario? If so, where |
| 34 |
> would they be documented? Searching for LIVECVS found a bunch of |
| 35 |
> repoman change discussions, but no documentation as to how to deal with |
| 36 |
> ebuilds that require this... |
| 37 |
> |
| 38 |
> Mike 5:) |
| 39 |
> |
Archives