Bill Campbell wrote: > On Sun, Dec 23, 2007, Johnny Hughes wrote: >> Johnny Hughes wrote: > ... >>>> 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? > ... >> We have been in touch with the upstream provider on this ... first some >> issues: >> >> The default prelink setup can take up to 2 weeks to rerun a full >> prelink. This is due to serveral settings in the file >> /etc/sysconfig/prelink. >> >> So, after an update, it may take up to 14 days for a file to get >> prelinked after it's libraries are updated. You can manually prelink >> sooner if required. >> >> It seems the only real thing affected by this is "rpm -V". > > A minor problem if one is trying to find changes on a possibly > cracked system. > > Personally I figure being able to verify a system at any time is > far more important than any possible optimization from prelinking > so remove/disable prelink. > Sure ... and that is an option for the user. RHEL ships with prelinking enabled by default, so CentOS will too. Does prelinking really help ... maybe for some things. It just depends on your priorities. Thanks, Johnny Hughes
Attachment:
signature.asc
Description: OpenPGP digital signature
_______________________________________________ CentOS mailing list CentOS@xxxxxxxxxx http://lists.centos.org/mailman/listinfo/centos
