Installing a system today, I ended up with openresolv failing to install because it wanted to overwrite systemd's /sbin/resolvconf. If it had a blocker on systemd[resolvconf] portage would have understood that it was safe to ignore the collision.
Can I ask why you (or emerge) wanted to install openresolv on a systemd system?
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=32967bb3205a21a38758f9e67b5642d13322cf1d commit 32967bb3205a21a38758f9e67b5642d13322cf1d Author: Ben Kohler <bkohler@gentoo.org> AuthorDate: 2021-07-20 10:40:48 +0000 Commit: Ben Kohler <bkohler@gentoo.org> CommitDate: 2021-07-20 10:41:14 +0000 net-dns/openresolv: block systemd[resolvconf] Closes: https://bugs.gentoo.org/802960 Package-Manager: Portage-3.0.20, Repoman-3.0.3 Signed-off-by: Ben Kohler <bkohler@gentoo.org> net-dns/openresolv/openresolv-3.12.0.ebuild | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
Thanks! (In reply to Ben Kohler from comment #1) > Can I ask why you (or emerge) wanted to install openresolv on a systemd > system? I actually have it installed on multiple systemd systems still, so it wasn't a transitory thing. It's installed because of networkmanager[resolvconf] -- which explicitly depends on openresolv: resolvconf? ( net-dns/openresolv ). I thought this was a bug but bug 669246 suggests that it is not (I still think it's not good that USE="systemd resolvconf" leads to this situation due to networkmanager). Cc'ing floppym@ so he sees this. Anyway, I have resolvconf enabled globally but disabled on systemd via package.use. Maybe I shouldn't have it enabled at all? Certainly seems like something needs to change.