Since the go compiler handles vcs's directly, this ebuild does not need to inherit or use any vcs eclasses. A patch will b attached.
Created attachment 397490 [details, diff] go-mtpfs-9999.ebuild.patch This is the patch that fixes this issue.
The "compiler" as you call it handles vcs directly in a manner completely inconsistent with the expected features of gentoo live packages. if smart-live-rebuild and emerge @smart-live-rebuild are not supported then this is a breakage not a fix.
Here is what happens when I run emerge @smart-live-rebuild: --- cut --- emerge: There are no sets to satisfy 'smart-live-rebuild'. The following sets exist: changed-deps downgrade installed live-rebuild module-rebuild preserved-rebuild profile rebuilt-binaries security selected selected-packages selected-sets system unavailable unavailable-binaries world x11-module-rebuild --- cut --- It looks to me like @smart-live-rebuild is not a standard portage set, so I do not feel we should reject this change since it depends on an optional feature.
Does the go compiler meet the Gentoo quality requirements, that is: 1. Cache download results in semi-permanent location so that we don't end up refetching on each build? 2. Support some kind of offline mode? (alike EVCS_OFFLINE) 3. [not obligatory but nice to have] Support splitting fetching and checking out phase?
