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: https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=0fa8481e9f0b193c36a4c4041b16f56de97e4d0a I suspect this code in the depgraph _serialize_tasks method may have prevented the blocker from solving, but I have not verified that: https://gitweb.gentoo.org/proj/portage.git/tree/pym/_emerge/depgraph.py?h=portage-2.3.26#n7674 if node == replacement_portage and \ mygraph.child_nodes(node, ignore_priority=priority_range.ignore_medium_soft): # Make sure that portage always has all of it's # RDEPENDs installed first. return False
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/proj/portage.git/commit/?id=c5ad40dbe8f74dcdb2b08d42240e217a8ef440e6 commit c5ad40dbe8f74dcdb2b08d42240e217a8ef440e6 Author: Zac Medico <zmedico@gentoo.org> AuthorDate: 2018-03-30 03:35:24 +0000 Commit: Zac Medico <zmedico@gentoo.org> 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 of portage. Bug: https://bugs.gentoo.org/651936 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: > !<app-portage/repoman-2.3.10
