Steve G wrote:
>Now try to get the -9 changed in rpm.
@@ -8,8 +8,8 @@
# Compress man pages
-COMPRESS="gzip -9 -n"
+COMPRESS="bzip2 -9 -n"
The patch is the easy part ;-)
>And it also makes little sense to bzip tarballs that end up in
>gzipped payloads imho.
I was referring to *.src.rpm's, rather than man pages. Apologies for the
It does when you realize that loading a man page is milliseconds
slower to bring
up using bzip2. And downloading updates via a modem can be 10's of minutes faster
when they are compressed with bzip2. Compare the size of virtually any tarball:
kde, kernel, open office, tetex, .... You can fit more packages on an iso CD,
Yep, user response time for man needs to be considered too. So does
build startup times
when uncompressing big honking tarballs from *.src.rpm's.
Looking through the bzip2 source code, it looks like its been
well. But, there is a little room for improvement - even in C and no assembler
has been added.
The threading is prolly a bigger win than any optimize, as bulk data
decompression is invariably i/o,
not cpu, bound. Trickier when a serial stream is used to concatenate
blocks, or blocks are chained, too.
73 de Jeff