sys-apps/util-linux-2.28 (current stable,) and sys-libs/libuuid-1.0.3 (marked ~*) both install /usr/include/uuid/uuid.h, /usr/lib64/pkgconfig/uuid.pc, and /usr/lib64/libuuid.so. Reproducible: Always Actual Results: First one emerged installs files, second one fails due to package collision. Expected Results: No conflict, or explicit depend of one on non-presence of the other.
Conflict still present with util-linux-2.33-r1 (didn't test with ~2.33.1)
the conflict is intentional, I wonder why libuuid was pulled in though
"equery d libuuid" doesn't show anything (I'm on amd64) so (although I can't remember what I was doing to discover the conflict over two years ago) I may have been led to that package attempting to solve some other problem, which seems to no longer present. However, as libuuid is only keyworded for "~sparc-solaris ~sparc64-solaris ~x64-solaris ~x86-solaris" I wonder if I just should never have been trying to install it on amd64, or if an explicit block should be added.
I'll add the block, but you never ever should have the need to install it yourself :)
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=24dde68a08d82a732cd6a94fcab9ca654502d175 commit 24dde68a08d82a732cd6a94fcab9ca654502d175 Author: Fabian Groffen <grobian@gentoo.org> AuthorDate: 2019-03-04 21:39:34 +0000 Commit: Fabian Groffen <grobian@gentoo.org> CommitDate: 2019-03-04 21:40:08 +0000 sys-libs/libuuid: block util-linux and native-uuid Bug: https://bugs.gentoo.org/631594 Signed-off-by: Fabian Groffen <grobian@gentoo.org> Package-Manager: Portage-2.3.51, Repoman-2.3.11 sys-libs/libuuid/libuuid-1.0.3.ebuild | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-)
I am thinking..... Bug with libuuid not fixed. Without it we are can not compile xfsdump. Or may be I dont know replacement?
with the block in place, you should have util-linux ... only
