Ryan Niebur wrote, on 31/08/11 05:22:
Hi Arthur,
On Sat, Aug 07, 2010 at 11:08:52PM +0930, Arthur Marsh wrote:
Package: debsums
Version: 2.0.48+nmu1
Severity: normal
After updating a single small package (subnetcalc) on this machine
with aptitude, debsums consumed 3 minutes of cpu time.
Surely it shouldn't take 3 minutes of cpu time to calculate the changed
md5 sums as a result of updating one small package?
Yes, that is odd.
I compared situations where debsums is disabled, debsums is doing
nothing, and debsums is generating md5sums for a single package
(including subnetcalc). I've tried using apt-get and aptitude. My
results were pretty much the same between those different situations.
Was this the first install you made after enabling debsums? If so it
would have generated missing md5sums for everything it could find a
.deb file for in your apt cache, so that could explain it taking
a little bit longer than expected.
That probably isn't a good enough explanation, though, because I also
removed the md5sums files of 7 packages that were still in my apt
cache, ran the debsums hook manually, and compared the timing. It
made a difference of a second or two. And all of these tests were on
a pretty old 500 MHz P3 machine, so I don't think it had any advantages.
Can you still reproduce this problem? If so, can you think of anything
that would lead to an explanation of why it takes longer on your machine?
I'm not sure what else I can try to reproduce the problem. I'll let
you know if I come up with any successful ideas, though.
Cheers,
Ryan
Thanks for the investigation. My guess is that due to this machine
having prelink installed, debsums was having to reverse the prelink
process for a large number of binaries in order to correct the correct
md5sums.
Regards,
Arthur.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
