On Fri, 2 Jun 2017 02:23:44 -0400 Alan Grimes <alonz...@verizon.net> wrote:
> without spending all day and all night cut-pasting filenames into > another terminal and running rm on them... Looking at the candidate you showed: k3b: version=2.0.3-r5 slot=4 stable version=17.04.1 slot=5 testing It seems like its plausible you recently changed your keywording choices somewhere from "arch" to "~arch", bringing a lot of untested upgrades with it. Or, you allowed portage to perform far more auto-unmasks than really made sense for what you're doing. I could be wrong though. But what appears to be the problem is you have 2 k3b versions, which, according to slots, should be permitted to be co-installed, but according to the files they install, can't be co-installed. This seems like possible cause for opening a bug on k3b, so that k3b:5 blocks against k3b:4 and vice versa. But as for the other cases you saw, I can't really comment, because its seldom the case that multiple packages are having file collisions for the same reason. The only usual reason for that sort of thing happening on a broad scale is /usr/ getting provisioned during install, and staying, but the contents index in /var/db/pkg getting lost somehow due to the segv + reboot, leaving the files there, but leaving portage with no memory of where they came from. I've had that sort of thing happen before, but its very rare.
pgpviBXX5ekHZ.pgp
Description: OpenPGP digital signature
