In bug 598080, comment #9, a user has reported that ncurses-6.0-r1 was removed by emerge autoclean: > Today, portage removed ncurses-6.0-r1, but 6.0 remained, as reported by > Daniel Augstin in Comment #7 > > BTW: I had to manually scroll my X terminal to find this message: > ------------------------------------------------------------------------ > >>> Auto-cleaning packages... > > sys-libs/ncurses > selected: 6.0-r1 > protected: 6.0 > omitted: none > > All selected packages: =sys-libs/ncurses-6.0-r1 > ------------------------------------------------------------------------ We can expect this behavior if the ncurses-6.0 ebuild is installed after the ncurses-6.0-r1, and then this slotmove is applied: profiles/updates/3Q-2015:slotmove ~sys-libs/ncurses-6.0 5 0
I've removed the slotmove, so that it won't cause any more damage: https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=ed7b895358b57dd9c426efc6ca776eeaacc53bc Without the slotmove, users upgrading from the old version of the nucurses-6.0 ebuild added in this commit can experience a file collision with the ncurses-6.0-r1 ebuild: https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=a8bc05519a12cd2bad582b23d8de7c4924b5bd7f So, we probably want to add a blocker like !~sys-libs/ncurses-6.0:5 to the ncurses-6.0-r1 ebuild. Does anyone see a reason not to add this blocker? Also, it seems that the ncurses-6.0 ebuild is useless, so is there reason not to remove it? It looks like we should have used a blocker instead of a slotmove in the first place. I guess the slotmove was a hack in order to avoid triggering slot-operator rebuilds?
(In reply to Zac Medico from comment #1) > I guess the slotmove was a hack in order to > avoid triggering slot-operator rebuilds? The slotmove does did not help for the slot-operator deps of installed packages, because portage doesn't support that for slot moves with versioned atoms, as noted in bug 558856, comment #7. It seems the purpose of the ncurses-6.0 ebuild is to satisfy the dependencies of installed packages having built slot-operator dependencies like sys-libs/ncurses:5/6= which are not affected by the slotmove. I expect that emerge has triggered rebuilds for such packages, building them against the newer 0/6 slot/subslot. So, nobody should need the ncurses-6.0 ebuild.
I'm actually now getting the following slot conflict, which doesn't seem to make sense (I don't have ncurses in my world file) Total: 9 packages (7 upgrades, 2 reinstalls, 2 binaries), Size of downloads: 44,715 KiB !!! Multiple package instances within a single package slot have been pulled !!! into the dependency graph, resulting in a slot conflict: sys-libs/ncurses:5 (sys-libs/ncurses-6.0:5/6::gentoo, ebuild scheduled for merge) pulled in by (no parents that aren't satisfied by other packages in this slot) (sys-libs/ncurses-5.9-r101:5/5::gentoo, binary scheduled for merge) pulled in by >=sys-libs/ncurses-5.2:5/5= required by (net-misc/netkit-telnetd-0.17-r10:0/0::gentoo, binary scheduled for merge) ^^^^^ When masking sys-libs/ncurses-6.0 it works fine
(In reply to Simon from comment #3) > >=sys-libs/ncurses-5.2:5/5= required by > (net-misc/netkit-telnetd-0.17-r10:0/0::gentoo, binary scheduled for merge) You need to rebuild that netkit-telnetd-0.17-r10 binary package against the ncurses 0/6 slot. Since the rebuild didn't happen automatically, I'm guessing that the netkit-telnetd-0.17-r10 ebuild is masked or unavailable (bug 602964 has a patch to report such cases).
