Bug 37465

I can't reproduce this, and nobody reported anything like this in the beta 
phase. Make sure you aren't using a broken ~/.termcap or ~/.terminfo. Also, 
make sure nobody messed up your termcap, ncurses or libtermcap packages.

This seems to have been caused by a bug in RPM (??!).  I had a copy of
libtermcap.so.2.0.5 from 1996 lying around in the /lib directory.  For some
reason I don't understand, installing libtermcap-2.0.8-26.i386.rpm creates
/lib/libtermcap.so.2.0.8 as a hard link to this old file instead of installing
the correct new file:

$ cd /lib
$ ls -l libtermcap*
lrwxrwxrwx    1 root     system         19 Apr 24 11:40 libtermcap.so.2 ->
libtermcap.so.2.0.8
-rwxrwxr-x    2 root     system      11419 Jul 28  1996 libtermcap.so.2.0.5
-rwxrwxr-x    2 root     system      11419 Jul 28  1996 libtermcap.so.2.0.8

I was able to repeat the rpm error by running "rpm -e --nodeps libtermcap"
(which removed libtermcap.so.2.0.8 but left libtermcap.so.2.0.5 in place), then
running "rpm -i libtermcap-2.0.8-26.i386.rpm", which recreated the above
situation.

At this point I was pretty puzzled.  I rebooted and forced an fsck just to make
sure I didn't have some bizarre filesystem corruption.  There were no errors.

Finally, I moved libtermcap.so.2.0.5 to another directory, removed the other two
files, and did "rpm -i --force libtermcap-2.0.8-26.i386.rpm".  This fixed the
problem:

$ ls -l libtermcap* 
lrwxrwxrwx    1 root     system         19 Apr 24 12:54 libtermcap.so.2 ->
libtermcap.so.2.0.8
-rwxr-xr-x    2 root     system      12120 Oct  7  2000 libtermcap.so.2.0.8

This is most definitely a local issue. Our best guess is that you installed 
some ridiculous package that owns a trigger on libtermcap and overwrites the 
library with its own files.

Does rpm -qf /lib/libtermcap.so.2.0.5 show anything?

This is definitely not a Red Hat package by the way, we've shipped 2.0.8 even 
in Red Hat Linux 4.2, which is as far back as our archives go.

Excellent guess.  I looked around some more, and found that the trigger script
causing the problem is in the Red Hat package anonftp-4.0-4.  I don't know where
the file /lib/libtermcap.so.2.0.5 came from originally, but its presence tickles
a bug in this trigger script.  Here are the key lines:

copy() { ln -f "$1" "$2" 2>/dev/null || cp -df "$1" "$2"; }
rm -f /var/ftp/lib/libtermcap.so.*.*.* &>/dev/null || :
copy /lib/libtermcap.so.*.*.* /var/ftp/lib

Stop a moment and consider what that copy() function is going to do when
/lib/termcap.so.*.*.* expands to more than one filename.  Yep, it will replace
the second expansion with a hard link to the first one.  That's exactly what
happened here.  The new 2.0.8 version got replaced with a hard link to the bogus
old 2.0.5 version.

Fixed in anonftp-4.0-5.

It's still partially a setup problem, though - you should never have 2 files 
matching libsomething.so.*.*.* because there's no need for the older one, 
especially not in /lib.