On Fri, Mar 27, 2020 at 7:33 AM Michał Górny <mgo...@gentoo.org> wrote: > > On Fri, 2020-03-27 at 11:29 +0000, Samuel Bernardo wrote: > > > Same question for unpack context when using directly the source > > repository with vcs functions. > > VCS ebuilds generally suck, for multiple reasons. We allow users to use > them but with minimal support. However, e.g. git-r3 supports local > mirrors to resolve some problems. >
Any guides on using that from an ebuild maintenance standpoint? The eclass docs make it appear more for local sysadmin use vs as a way to distribute things, but I could be reading into it. Usually my solution to VCS ebuilds when that is all upstream supports is to just create my own github mirror of the repo, tag an appropriate commit, and then fetch the resulting tarball directly as a non-VCS ebuild. Essentially I end up running my own private fork of upstream. At least, this is what I do for actual releases that upstream can't be bothered to release properly - for a live -9999 VCS ebuild I just point to upstream. I don't believe Gentoo has any kind of recommended/standardized solution for this, but having ebuilds point to my own private fork of things obviously is non-ideal. However, I think it is still more transparent than just bundling up a tarball manually and sticking it in my devspace since at least with my forked repo everybody can see where it came from and what state it is in, and of course it is easier to maintain. If there is a more preferred way of doing this I'd be interested to hear about it. -- Rich
