Bug 230039

Summary: save_y2logs should turn off signature checking while running rpm -qa
Product: [openSUSE] openSUSE 10.3 Reporter: Andreas Hanke <andreas.hanke>
Component: YaST2Assignee: Stefan Hundhammer <shundhammer>
Status: RESOLVED INVALID QA Contact: Jiri Srain <jsrain>
Severity: Enhancement    
Priority: P5 - None    
Version: unspecified   
Target Milestone: ---   
Hardware: All   
OS: All   
Whiteboard:
Found By: Other Services Priority:
Business Priority: Blocker: ---
Marketing QA Status: --- IT Deployment: ---

Description Andreas Hanke 2006-12-20 20:03:24 UTC
The save_y2logs script could be a bit faster if it would run rpm -qa with --nosignature --nodigest.

The additional information gathered by not turning it off is currently thrown away (because rpm writes it to stderr and the script captures stdout only), so there's no point in leaving it on.
Comment 2 Stefan Hundhammer 2007-01-03 14:40:52 UTC
Is this an issue to merely make it faster, or does it actually cause any problems with those checks on?

save_y2logs is not exactly meant to be performance-tuned - it's a debugging tool. ;-)
Comment 3 Andreas Hanke 2007-01-05 01:26:59 UTC
It doesn't cause problems as-is. --nosignature --nodigest would just be an enhancement.

Some performance data:

As-is:

real    0m1.691s
user    0m0.896s
sys     0m0.096s

real    0m1.720s
user    0m0.948s
sys     0m0.068s

real    0m1.750s
user    0m0.924s
sys     0m0.120s

real    0m1.621s
user    0m0.908s
sys     0m0.088s

real    0m1.683s
user    0m0.928s
sys     0m0.084s

--nosignature --nodigest:

real    0m0.829s
user    0m0.348s
sys     0m0.072s

real    0m0.918s
user    0m0.256s
sys     0m0.116s

real    0m0.829s
user    0m0.276s
sys     0m0.124s

real    0m0.812s
user    0m0.276s
sys     0m0.144s

real    0m0.849s
user    0m0.284s
sys     0m0.128s

It is somewhat faster. The "build" script also uses --nosignature --nodigest in some places while setting up the build root.
Comment 4 Stefan Hundhammer 2007-01-05 10:26:23 UTC
That's what I had thought. It's a mere performance optimization.

Frankly, no. ;-)

Optimizing for performance is not something to do for a debugging tool, and that's what it is. Even less if the gain does not really save anything. Getting it down from 1.6 seconds to 0.8 seconds? No way I am going to make that script any more complex than it absolutely has to for that kind of thing. We are not optimizing the exceptional case, even less the debugging case.