Hallo, Am Mon, 03 Mai 2010, Philipp Thomas schrieb:
* Sascha 'saigkill' Manns (samannsml@directbox.com) [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. -- To unsubscribe, e-mail: opensuse-programming-de+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-programming-de+help@opensuse.org