Re: Calibre: manpage not gzipped

Hallo,

Am Mon, 03 Mai 2010, Philipp Thomas schrieb:
>* Sascha 'saigkill' Manns ([email protected]) [20100502 07:05]:
>> momentan erhalte ich als Warnung beim bauen diese Meldung:
>> 
>> calibre.x86_64: W: manpage-not-gzipped 
>> /usr/share/calibre/man/man1/lrf2lrs.1calibre.bz2
>
>Ja, weil die Seiten mit bzip2 und nicht mit gzip gepackt wurden.
>
>>Bestimmt lässt sich sowas doch in einer Schleife lösen. Hat jemand eine
>>Idee dazu?
>
>Das vernünftigste wäre es, direkt in den Baumechanismus einzugreifen um das
>zu ändern. Ansonstgen würde ich folgendes vorschlagen:

Also: eigentlich ist es Aufgabe der rpm-Paketierer/rpmlint-Maintainer
rpmlint und /usr/lib/rpm/brp-compress "im Gleichschritt" anzupassen.

BTW: ich halte nix davon, manpages per bzip2 (oder sonstwas ausser
gzip zu komprimieren). Bei normalen (v.a. wohl sogar engl.) Text
komprimiert gzip i.d.R. praktisch gleich oder sogar effektiver als
bzip, lzma etc.  Und v.a. mit wesentlich geringerer CPU-Last beim
(de-)komprimieren:

# mkdir /mnt/tmp
# mount -t tmpfs -o size=32M none /mnt/tmp
# mkdir /mnt/tmp/dh
# chown dh.dh /mnt/tmp/dh
$ mv file.lst /mnt/tmp/dh/
$ cd /mnt/tmp/dh/
$ ls -lh file.lst   ### enthält eine Liste von Dateinamen + Größen
-rw-r--r--   1 dh       dh           8.7M May  3 21:54 file.lst

Bei den folgenden Kommandos jew. das mit der kürzesten Zeit von je 3
Versuchen (und sonst keiner CPU-/HDD-relevanten Aktivität):

$ { time gzip -c file.lst > file.lst.gz ; } 2>&1 | grep real
real    0m2.065s
$ { time bzip2 -c file.lst > file.lst.bz2 ; } 2>&1 | grep real
real    0m20.234s
$ { time lzma -c file.lst  > file.lst.lzma ; } 2>&1 | grep real
real    1m35.199s
$ { time 7z a file.lst.7z file.lst ; } 2>&1 | grep real
real    0m22.873s
$ { time zip -9 file.lst.zip file.lst ; } 2>&1 | grep real
real    0m4.125s
$ { time rar -ierr p file.lst.rar >/dev/null ; } 2>&1 | grep real
real    0m0.590s

$ l -A --sort=size | cut -d 'h' -f3-
total 14824
        9135649 May  3 21:54 file.lst
        1237415 May  3 22:13 file.lst.gz
        1175565 May  3 22:32 file.lst.zip
        1017892 May  3 22:24 file.lst.rar
         929200 May  3 22:15 file.lst.bz2
         855836 May  3 22:36 file.lst.7z
         748515 May  3 22:20 file.lst.lzma

Noch relevanter im Kontext "manpages komprimieren" allerdings das
dekomprimieren (wieder jew. das schnellste von 3 Aufrufen):

$ { time gzip -dc file.lst.gz > /dev/null ; } 2>&1 | grep real
real    0m0.323s
$ { time bzip2 -dc file.lst.bz2 > /dev/null ; } 2>&1 | grep real
real    0m2.542s
$ { time lzma -dc file.lst.lzma  > /dev/null ; } 2>&1 | grep real
real    0m0.847s
$ mkdir t
$ { time yes | 7z -bd e -ot file.lst.7z  ; } 2>&1 | grep real
real    0m1.234s
$ { time unzip -p file.lst.zip  >/dev/null ; } 2>&1 | grep real
real    0m0.320s
$ { time rar -ierr p file.lst.rar >/dev/null 2>&1 ; } 2>&1 | grep real
real    0m0.597s

Hier schlägt sich lzma erstaunlich gut. Komprimieren lahm, aber da die
Dekomprimierung recht "schnell" ist, kann es evtl. ein Kompromiss sein
_WENN_ es auf den Platz "on Disk" wirklich ankommt. Würde ich aber
dennoch nicht bei manpages verwenden. Sonst aber oft.

BTW: das 7z CLI-Interface is ja wohl komplett kapott. Oder? Zumindest
was das extrahieren nach stdout angeht ...

Jedenfalls: wenn man sich jetzt noch anschaut, wie "gut" oder
"schlecht" das Interface von gzip/zip sind, dann bleib ich bei o.g.:
manpages etc. sollten per gzip komprimiert werden. Punkt. Aus.

Go figure.

-dnh

-- 
Real programmers use chmod +x /dev/random and cross their fingers
         -- Comment found in a vi/emacs flamewar on slashdot.