The current dev-util/android-studio-1.5.1.0.141.2456560 has in its RDEPEND || ( >=sys-libs/ncurses-5.9-r3:5/5[abi_x86_32(-)] >=sys-libs/ncurses-5.9-r3:0/5[abi_x86_32(-)] ) which is a real bummer for people who have already upgraded to ncurses-6.0[-r1] because ncurses is not slotted (in the sense that parallel installation is possible). Just for trying, I installed android-studio with (only) ncurses-6.0 installed, and I found no obvious problem. I made no exhaustive tests, of course. Perhaps the current version of android-studio also works with ncurses-6.0? So, if there is not a good reason to explicitly block the ncurses:*/6 subslot, perhaps one could add >=ncurses-6.0:6/6[abi_x86_32(-)] >=ncurses-6.0:0/6[abi_x86_32(-)] to the above || clause or perhaps simply replace the whole clause by e.g. >=sys-libs/ncurses-5.9-r3:*[abi_x86_32(-)] If only some tool(s) breaks, perhaps one could add a ncurses6 USE-flags which describes roughly what will break?
6.0 wont work. most of android-studio is java so it doesnt matter but there are a few binary parts that require .so.5 ncurses is slotted. :0 is the "full" one that installs header files and stuff. :0/5 is .so.5 and :0/6 is .so.6 :5 is the library-only package which installs libncurses.so.5 (which is what android-studio needs) :6 does not exist but would be the lib-only package for libncurses.so.6 in the future. Keywords: 5.9-r5:0/5: stable. this is what stable users actually use. Keywords: 5.9-r99:5/5: stable. this one is a noop and pulls in -r5 because of a slotmove issue in the past. Keywords: 5.9-r101:5/5: ~arch. you need to install this for android studio. Keywords: 6.0:5/6: ~arch. a noop to pull in 6.0-r1 because of the same slotmove issue. Keywords: 6.0-r1:0/6: ~arch. unstable users are on this. you are on ~arch right? what versions of ncurses do you have installed currently? it should be 6.0 and 5.9-r101.
You are right, =sys-libs/ncurses-5.9-r101:5 really installs only the *.so.5 files, and the slot conflict I got does not come from ncurses itself (I did not read carefully enough the blocker in ncurses-6.0-r1). On my system, the reason for the strange slot conflict was only one ebuild: x11-terms/st-0.6-r1 which has the RDEPEND blocker !<sys-libs/ncurses-6.0 Unless st itself has a serious bug, I suppose that this is a bug in the st-0.6-r1.ebuild and that the RDEPEND entry in that ebuild should actually be !<sys-libs/ncurses-6.0:0 or perhaps even something like >=sys-libs/ncurses-6.0:0/= I change the bug summary correspondingly.
!<sys-libs/ncurses-6.0 does indeed look wrong. That means having no ncurses installed at all is okay to portage which is probably not right since the older rev depended on it. it should probably be: RDEPEND=">=sys-libs/ncurses-6.0:0="
(In reply to Jason Zaman from comment #3) > it should probably be: > RDEPEND=">=sys-libs/ncurses-6.0:0=" This modification made st coexist with current ncureses, and it seems working properly here. Please update the dependency.
I have set a non-versioned dependency on sys-libs/ncurses:= in stable x11-terms/st-0.6-r1 since the only problem there would be the terminfo support, which can easily be worked around by setting TERM appropriately through savedconfig. In 0.7 and 9999 I have changed the dependency as suggested above.
