Description of problem: tux:~ # ls -la /usr/lib/libncurses.so.5 lrwxrwxrwx 1 root root 12 15. Feb 20:01 /usr/lib/libncurses.so.5 -> libcurses.so tux:~ # tux:~ # rpm -qf /usr/lib/libncurses.so.5 file /usr/lib/libncurses.so.5 is not owned by any package tux:~ # tux:~ # rm -f /usr/lib/libncurses.so.5 tux:~ # tux:~ # ls -la /usr/lib/libncurses.so.5 ls: cannot access /usr/lib/libncurses.so.5: No such file or directory tux:~ # tux:~ # rpm -Uvh --force ncurses-5.6-4.20070210.fc7.i386.rpm Vorbereiten... ########################################### [100%] 1:ncurses ########################################### [100%] tux:~ # tux:~ # ls -la /usr/lib/libncurses.so.5 lrwxrwxrwx 1 root root 12 15. Feb 20:15 /usr/lib/libncurses.so.5 -> libcurses.so tux:~ # tux:~ # rpm -qf /usr/lib/libncurses.so.5 file /usr/lib/libncurses.so.5 is not owned by any package tux:~ # Version-Release number of selected component (if applicable): ncurses-5.6-4.20070210 How reproducible: Everytime, see above. Actual results: File /usr/lib/libncurses.so.5 is not owned by any package. Expected results: The file /usr/lib/libncurses.so.5 should be owned by ncurses or the file should not exist/created by any installation.
ldconfig creates the file, not sure why. libtinfo is very similar, but ldconfig doesn't create a symlink for it.
What matters is the /usr/{lib,lib64}/libcurses.so -> libncurses.so symlink. As the real library it ultimately points to isn't in the same directory and it has different name, ldconfig will create the symlink for it. libncurses.so.5 (the name of the symlink) is the SONAME of the library libcurses.so points to. The easiest is probably not make libcurses.so as a symlink, but instead a linker script. rm -f $RPM_BUILD_ROOT%{_libdir}/libcurses.so echo 'INPUT (-lncurses)' > $RPM_BUILD_ROOT%{_libdir}/libcurses.so Untested, but should work right.
Thanks. Fixed in ncurses-5.6-5.20070217.fc7.
This "fix" breaks gdb and emacs on x86_64. See BZ#229737, BZ#253125 This bug is in today's rawhide, please do not assume that its been fixed. This bug should be re-opened. root@ontap:lib64# ls -l *curses* -rw-r--r-- 1 root root 17 2007-08-13 08:21 libcurses.so lrwxrwxrwx 1 root root 18 2007-08-16 18:40 libcursesw.so -> libncursesw.so.5.6 lrwxrwxrwx 1 root root 27 2007-08-16 18:40 libncurses.so -> ../../lib64/libncurses.so.5 lrwxrwxrwx 1 root root 12 2007-08-17 08:41 libncurses.so.5 -> libcurses.so lrwxrwxrwx 1 root root 16 2007-08-16 18:40 libncursesw.so -> libncursesw.so.5 lrwxrwxrwx 1 root root 18 2007-08-16 18:40 libncursesw.so.5 -> libncursesw.so.5.6 -rwxr-xr-x 1 root root 183264 2007-08-13 08:21 libncursesw.so.5.6
John, let's reopen if you think so.
*** Bug 253125 has been marked as a duplicate of this bug. ***
Please remove the /usr/lib64/libncurses.so.5 symlink and everything will work again. This happens only when upgrading from rawhide packages from Nov 2006-Feb 2007. Upgrading ncurses from F6 to F7 and from F7 to current rawhide is ok.
Finally we need to have a packaged /usr/lib[64]/libncurses.so.5, otherwise ldconfig will create the symlink manually - which is unpackaged.
OK. Comment #7 works for me. I think the bug should still stay open so that others can find it and ultimately find this manual fix. This fix should be done directly from the ncurses-devel rpm to cover users that upgrade incrementally. Or a fix based on Comment #8. Then this bug can be closed.
The library and the symlink were moved to /lib64. Removing the wrong symlink in post scriptlet is not an option since bash depends on ncurses. I can keep this bug open for a while, but it's really WONTFIX. Actually it's not a bug, it's a feature, it will catch ncurses binaries that have "RPATH /usr/lib64" encoded in them ;).
This is NEVER NEVER NEVER WONTFIX, because it violates against the Fedora Packaging Guidelines.
Hm, which guideline are you referring to?
Re Comment #10, are you saying that this is a bug in gdb and emacs? Have bugs been opened against them? Do you really want such a poorly documented "feature" in ncurses to be taking on this role?
(In reply to comment #12) > Hm, which guideline are you referring to? http://fedoraproject.org/wiki/Packaging/Guidelines#head-a1dfb5f46bf4098841e31a75d833e6e1b3e72544 (In reply to comment #13) > Re Comment #10, are you saying that this is a bug in gdb and emacs? > Have bugs been opened against them? GDB has no such Bug opened but it is now being rebuilt without RPATH.
Filed bug #253872 for emacs.
Closing, the bug from the original report was fixed in ncurses-5.6-5.20070217.fc7.
Yes, but the maintainer reverted it again somewhen.
No, it's still fixed. ldconfig doesn't create the symlink /usr/lib/libncurses.so.5 -> libcurses.so. It was fixed by putting "INPUT(-lncurses)" string in /usr/lib/libcurses.so.