The USE flag ncurses in nano (at least 2.2.5, but I guess many other earlier version as well) is only used in a very unintuitive way: its meaning is not “use ncurses/don’t use ncurses”, but rather “if I say don’t use ncurses and use slang, then do use slang”, which to me is really redundant. In other words, this is from the DEPENDS: >=sys-libs/ncurses-5.2[unicode?] !ncurses? ( slang? ( sys-libs/slang ) ) (Besides, shouldn’t they be RDEPENDS? nano does depend on ncursesw.so) And in src_configure: use ncurses \ && myconf="--without-slang" \ || myconf="${myconf} $(use_with slang)" So again, USE=-ncurses is only a “permission” to use slang, instead of controlling whether or not ncurses is to be used. I believe the flag should either have its meaning fixed (that is, function as expected - I don’t know if nano can be built without ncurses, though), or be removed altogether.
Actually, it’s “if I say don’t use ncurses and use slang, then do use slang AND ncurses”, at least in terms of portage dependencies. I don’t know if compiled that way, nano still depends on ncursesw.so .
this is by design. nano can support only one interface -- ncurses or slang. since slang sucks, USE=ncurses gets preference over slang. you must USE="-ncurses slang" in order to get a slang based nano.
Okay, I see that USE=ncurses here really means USE=i-know-slang-sucks. I still think it should be impossible to emerge nano without either slang or ncurses, since that will act as if USE=ncurses was actually specified. How about adding: RDEPEND="${DEPEND} !slang? ( =${CATEGORY}/${PF}[ncurses] ) " This will cause emerge to refuse USE='-ncurses -slang' for nano, thereby making explicit the need for ncurses even without looking at the dependency tree. (And will also fix the lack of RDEPENDS.)
current policy is to make things smooth when possible. when an ebuild requires a choice from multiple options (which are exclusive), then the ebuild should provide USE flags for all of them (using standard names), and select a default for the user when none are opted for, or automatically resolve the conflict. calling `die` on conflicting USE flags is almost always frowned upon, and i dont think this case is exception worthy. ewarn is sometimes used to inform people of the resolution, but i dont think this is important enough either. nano has operated this way for over 5 years and you're the first to notice/care/complain.