As we know, it's quite an issue to decide between building ncurses with or without widechar support. Right now Gentoo has adopted a behaviour which prevents system deaths due to ncurses linking trouble, but at the same time effectively kills off unicode support in 99% of console applications (which, for a non-english speaker who uses the console daily, is unacceptable). See bug #106820 Saying that ebuilds should explicitly link to the widechar ncurses installed under a highly nonstandard prefix might be safe or "standard", but it's unrealistic. Also, unicode support in console would mean unicode support in cat, gcc, bash and other basic system tools, which, if explicitly linked to the ncursesw libs, would still kill the whole system off, should the unicode USE flag be removed, and ncurses reemerged. So it's a choice between no i18n on the console, and the sword of Damocles hanging above the head of all unicode users in the form of a system-destroying dynamic linking issue. I think the solution is quite obvious. Other similar issues, like hardened builds, are managed in Gentoo by profiles. A single package - ncurses - might semm a little thing to make a whole profile for, but let's look at it at another light: The whole behaviour of the console hangs on the unicode issue, which also has the potential of completely wrecking a functional installation. Doesn't sound so small now. A unicode profile should be created, where the widechar ncurses is the default (only) ncurses, and *w.so files are symlinked to *.so, to emulate the narrowc libs.
Sorry but creating *huge* maintenance overhead for something that's already implemented via USE=unicode is neither sane nor acceptable solution to work around a trivial issue. If you have some better solution for ncurses ebuild itself, file a bug with a patch. Separate profiles, heck no :)
The whole issue is that it's NOT implemented! Have you had a look at the ncurses ebuild lately? I've filed around 2 bugs with proposed fixes already, and all of them were rejected. I'm stuck with using a custom-made ebuild in my overlay, but I'm pretty sure that there are people out there who would be happy to have unicode on their consoles out of the box.
(In reply to comment #2) > The whole issue is that it's NOT implemented! Have you had a look at the > ncurses ebuild lately? What's not implemented, USE=unicode? Sorry, as said a separate profile to work around a trivial issues that requires to do `emerge --oneshot ncurses` after switching to unicode for a couple of ebuilds that don't compile otherwise is simply a no-go. (Nor is bugzilla a proper place to suggest new profiles, we have gentoo-dev mailing list for such things, though that point is pretty much moot for this particular suggestion, it won't be done).
(In reply to comment #3) > (In reply to comment #2) > > The whole issue is that it's NOT implemented! Have you had a look at the > > ncurses ebuild lately? > > What's not implemented, USE=unicode? What's not implemented is a proper wide curses installation that's available to applications that rely on the standard header and standard library name. That's the whole point of bug #106820, and that's what will never be fixed, apparently.
