But number 6941 reports that when ncurses 5.0 is installed, the ncurses 4.0 libraries disappear. The bug is marked resolved, and there's a claim in it that the problem is fixed in ncurses-5.0-2. I did not find that to be the case. I just installed ncurses-5.0 and it blew away my ncurses 4 libraries, as reported by "rpm --verify ncurses". I had to install the symbolic links by hand after unpacking the ncurses 5 source RPM to figure out what they were supposed to be. Speaking of which, the links created in the install rules of the spec file for ncurses 5.0 shouldn't be absolute. That is, rather than linking libncurses.4, libpanel.4, etc., to /usr/lib/libncurses.5, /usr/lib/libpanel.5, etc., the links should just point to "lib<whatever>.so.5" in the same directory.
I found out that ldconfig was killing the ncurses 4 links for some reason, after rebuilding ldconfig (same version) the problem went away. All this under a powerpc machine so it might be unrelated
It's fixed now (the .so.5 has just been renamed to .so.4, there are no API changes).
Although the API is the same, the ABI is different. The data structures that ncurses library and applications use depends on the definition of 'bool' in curses.h. 'bool' is defined to be 'char' on ncurses-5.0 (on i386 platform) while it can vary on ncurses-4.2 depending on whether a C++ compiler is present on the building host. This problem has already triggered the bug number 4573. So I think sharing the same library files for ncurses 5.0 and ncurses 4.2 is a bad idea. Binaries compiled on RH6.1 will dump core on the next version of RH.