Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 167313 - unicode profile suggestion (circumvent ncursesw issues)
Summary: unicode profile suggestion (circumvent ncursesw issues)
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Eclasses (show other bugs)
Hardware: All Linux
: High enhancement (vote)
Assignee: Gentoo Linux bug wranglers
Depends on:
Reported: 2007-02-17 10:38 UTC by Jozsef Daniel
Modified: 2007-02-17 16:11 UTC (History)
1 user (show)

See Also:
Package list:
Runtime testing required: ---


Note You need to log in before you can comment on or make changes to this bug.
Description Jozsef Daniel 2007-02-17 10:38:45 UTC
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 * files are symlinked to *.so, to emulate the narrowc libs.
Comment 1 Jakub Moc (RETIRED) gentoo-dev 2007-02-17 10:44:28 UTC
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 :)

Comment 2 Jozsef Daniel 2007-02-17 10:51:22 UTC
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.
Comment 3 Jakub Moc (RETIRED) gentoo-dev 2007-02-17 10:56:56 UTC
(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).

Comment 4 Harald van Dijk (RETIRED) gentoo-dev 2007-02-17 16:11:25 UTC
(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.