So, tldr; Github will tarball up specific commits (or master) for you to add to SRC_URI.
I ended up using the github API to pull down a tarball of the git repo, rather than using git to pull it down. I suppose that offers the ability to Manifest it and check for changes, but I now have to encode the fixed commit into every version of the ebuild because the only location it's recorded is in the submodule commit hash of the package's repo. I could have it live in the PV, but I think that'd lead to potential version sorting errors if people try and use copies of the ebuild. Making typeshed its own package doesn't help because it's installed under /usr/share/mypy/typeshed, not /usr/share/typeshed so it really is part of mypy (for now). So I'll see how this goes and listen for feedback... Mike 5:) On 11/03/18 18:05, Mike Auty wrote: > Hiya, > > I'm trying to update/package up mypy for the main tree which, whilst it > provides a release tarball, relies upon a data library (typeshed) which > does not provide releases. The recommended method of installation by > upstream is to use git submodules (which the ebuild will do happily), > but repoman rightly complains about LIVEVCS issues. > > Is the current recommended method for dealing with this to manually > create a tarball and stash it on dev.gentoo.org somewhere accessible or > are there updated guidelines for this kind of scenario? If so, where > would they be documented? Searching for LIVECVS found a bunch of > repoman change discussions, but no documentation as to how to deal with > ebuilds that require this... > > Mike 5:) >
signature.asc
Description: OpenPGP digital signature
