Can anybody explain to me what's going on here? This is a CentOS 4 i386 system.
[root@edison ~]# rm -f /etc/prelink.cache [root@edison ~]# /etc/cron.daily/prelink [root@edison ~]# rpm -qf /usr/bin/sqlite3 sqlite-3.3.6-2 [root@edison ~]# rpm --verify sqlite prelink: /usr/bin/sqlite3: at least one of file's dependencies has changed since prelinking S.?..... /usr/bin/sqlite3 [root@edison ~]# rpm -q --dump sqlite | grep "bin/sqlite3" /usr/bin/sqlite3 29044 1178360479 70e7158185e01e23dd2a62fa00f0f752 0100755 root root 0 0 0 X [root@edison ~]# md5sum /usr/bin/sqlite3 6e4b1dc7b0b5ade26448ed700c33e05f /usr/bin/sqlite3 [root@edison ~]# prelink -u /usr/bin/sqlite3 [root@edison ~]# md5sum /usr/bin/sqlite3 70e7158185e01e23dd2a62fa00f0f752 /usr/bin/sqlite3 [root@edison ~]# rpm --verify sqlite [root@edison ~]# prelink -f /usr/bin/sqlite3 prelink: /usr/lib/libncurses.so.5.4: .debug_loc adjusting unfinished [root@edison etc]# md5sum /usr/bin/sqlite3 70e7158185e01e23dd2a62fa00f0f752 /usr/bin/sqlite3 [root@edison etc]#
How did the RPM database have the right values for the sqlite3 file before prelink was run? Or, another way, why was the file different in the first place, that running prelink against it fixed it? And if "undoing" the prelink changed something, why wasn't it "changed back" when I ran prelink against the sqlite3 file the second time?
Finding this confusing as H__L.
I have *alot* of files on this system with this issue - I discovered this while debugging a problem with MailScanner. And, why do I see similar behavior on another system that's freshly built? EG: just ran the installer and "yum update" and see the same issue with a smaller number of files?
-Ben
-- Only those who reach toward a goal are likely to achieve it.