I tried using a blocker in the portage-2.3.14 ebuild but then I the blocker here because I experienced an issue where emerge did not resolve the blocker automatically:
I suspect this code in the depgraph _serialize_tasks method may have prevented the blocker from solving, but I have not verified that:
if node == replacement_portage and \
# Make sure that portage always has all of it's
# RDEPENDs installed first.
The bug has been referenced in the following commit(s):
Author: Zac Medico <firstname.lastname@example.org>
AuthorDate: 2018-03-30 03:35:24 +0000
Commit: Zac Medico <email@example.com>
CommitDate: 2018-03-30 03:47:55 +0000
depgraph._serialize_tasks: resolve portage/repoman blockers (bug 651936)
When ensuring that all runtime dependencies are installed before
a new instance of portage, ignore uninstalls. This makes it possible
to solve a blocker between a new version of portage and an older
version of repoman, where an uninstall task for the older version
of repoman appears in the runtime dependencies of the new instance
pym/_emerge/depgraph.py | 12 +++++++-----
1 file changed, 7 insertions(+), 5 deletions(-)}
The blocker will not solve automatically until people have the next version of portage installed, so we should not add the blocker until the next version of portage has been stabilized.
The portage-2.3.43 ebuild blocks repoman-2.3.10.
(In reply to Zac Medico from comment #3)
> The portage-2.3.43 ebuild blocks repoman-2.3.10.
Actually it's less than repoman-2.3.10: