[dev-libs/libvterm] Live ebuild depends on 'bzr' eclass, which doesn't exist anymore in Portage

[Dr-Terrible]

emerge then fails with:

ERROR: dev-libs/libvterm-9999-r2::raiagent failed (depend phase):
 *   bzr.eclass could not be found by inherit()
 *
 * Call stack:
 *                 ebuild.sh, line 609:  Called source '/usr/portage/overlays/raiagent/dev-libs/libvterm/libvterm-9999-r2.ebuild'
 *   libvterm-9999-r2.ebuild, line   6:  Called inherit 'multilib' 'bzr' 'flag-o-matic'
 *                 ebuild.sh, line 290:  Called die
 * The specific snippet of code:
 *              [[ -z ${location} ]] && die "${1}.eclass could not be found by inherit()"
 *
 * If you need support, post the output of `emerge --info '=dev-libs/libvterm-9999-r2::raiagent'`,
 * the complete build log and the output of `emerge -pqv '=dev-libs/libvterm-9999-r2::raiagent'`.
 * Working directory: '/usr/lib/python3.7/site-packages'
 * S: '/var/tmp/portage/dev-libs/libvterm-9999-r2/work/libvterm-9999'

[leycec]

Back to Gentoo Land. I sadly have no idea how to resolve this to everyone's satisfaction. I'd love to preserve live libvterm support, but:

• bzr.eclass has been officially last-rited. Technically, we could get around that by just importing the most recent bzr.eclass commit from the Portage tree into this overlay – except...
• dev-vcs/bzr has also been officially last-rited. This makes sense, because Bazaar has been effectively dead since 2017 and remains tied-at-the-hip to Python 2, which is also now effectively dead. Technically, we could get around that by also importing the most recent dev-vcs/bzr commit from the Portage tree into this overlay – except that python:2 is also going away shortly, so that would be cray-cray.

My other thought was to just refactor our live libvterm ebuild to fetch tarball snapshots of the most recent libvterm commits (i.e., HEAD) from the existing Bazaar repo – except Portage sensibly requires tarballs to be explicitly checksummed and I would have no reasonable way of doing that.

In short, there are no good solutions. The onus lies on Paul Evans to host his codebases under a sane, well-maintained DVCS. git is the obvious choice, but I'd settle for Mercurial. Until then, I'm reluctantly last-riting libvterm from our overlay. It is a sad day indeed. :sob:

^{P.S. Please reopen this if you think of something brilliant.}