CentOS - Dec 2007 - Prelink: Something's happening here

Can anybody explain to me what's going on here? This is a CentOS 4 i386 
system. 

[root at edison ~]# rm -f /etc/prelink.cache 
[root at edison ~]# /etc/cron.daily/prelink
[root at edison ~]# rpm -qf /usr/bin/sqlite3
sqlite-3.3.6-2
[root at edison ~]# rpm --verify sqlite
prelink: /usr/bin/sqlite3: at least one of file's dependencies has changed 
since prelinking
S.?.....    /usr/bin/sqlite3
[root at edison ~]# rpm -q --dump sqlite | grep "bin/sqlite3"
/usr/bin/sqlite3 29044 1178360479 70e7158185e01e23dd2a62fa00f0f752 0100755 
root root 0 0 0 X
[root at edison ~]# md5sum /usr/bin/sqlite3
6e4b1dc7b0b5ade26448ed700c33e05f  /usr/bin/sqlite3
[root at edison ~]# prelink -u /usr/bin/sqlite3
[root at edison ~]# md5sum /usr/bin/sqlite3
70e7158185e01e23dd2a62fa00f0f752  /usr/bin/sqlite3
[root at edison ~]# rpm --verify sqlite
[root at edison ~]# prelink -f /usr/bin/sqlite3 
prelink: /usr/lib/libncurses.so.5.4: .debug_loc adjusting unfinished
[root at edison etc]# md5sum /usr/bin/sqlite3
70e7158185e01e23dd2a62fa00f0f752  /usr/bin/sqlite3
[root at 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. 

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

Benjamin Smith wrote:
> Can anybody explain to me what's going on here? This is a CentOS 4 i386
> system. 
> 
> [root at edison ~]# rm -f /etc/prelink.cache 
> [root at edison ~]# /etc/cron.daily/prelink
> [root at edison ~]# rpm -qf /usr/bin/sqlite3
> sqlite-3.3.6-2
> [root at edison ~]# rpm --verify sqlite
> prelink: /usr/bin/sqlite3: at least one of file's dependencies has
changed
> since prelinking
> S.?.....    /usr/bin/sqlite3
> [root at edison ~]# rpm -q --dump sqlite | grep "bin/sqlite3"
> /usr/bin/sqlite3 29044 1178360479 70e7158185e01e23dd2a62fa00f0f752 0100755 
> root root 0 0 0 X
> [root at edison ~]# md5sum /usr/bin/sqlite3
> 6e4b1dc7b0b5ade26448ed700c33e05f  /usr/bin/sqlite3
> [root at edison ~]# prelink -u /usr/bin/sqlite3
> [root at edison ~]# md5sum /usr/bin/sqlite3
> 70e7158185e01e23dd2a62fa00f0f752  /usr/bin/sqlite3
> [root at edison ~]# rpm --verify sqlite
> [root at edison ~]# prelink -f /usr/bin/sqlite3 
> prelink: /usr/lib/libncurses.so.5.4: .debug_loc adjusting unfinished
> [root at edison etc]# md5sum /usr/bin/sqlite3
> 70e7158185e01e23dd2a62fa00f0f752  /usr/bin/sqlite3
> [root at 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,

I can verify that I see the same thing on centos-4.6 fully updated right
now.

When running "rpm -Va" I have several (dozen :D) RPMS that show the:

"at least one of file's dependencies has changed since prelinking"

The good news (or bad news depending on your point of view) is that I
also see the same thing on a fully updated RHEL-4.6 AS install.

I am currently doing a virgin RHEL-4.6 install from the ISOs to see if
it happens with the base 4.6 or only after updates.

I will post when I know more.

Thanks,
Johnny Hughes

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 252 bytes
Desc: OpenPGP digital signature
URL:
<http://lists.centos.org/pipermail/centos/attachments/20071219/3ce932db/attachment-0002.sig>