spkg podruhé (diskuse)

[unchallenger]

Podle těch požadavků nakonec napíšeš librpm, akorát to nebude portabilní, nebude to pořádně otestované, nebude to mít API pro další jazyky a pravověrní Slackwaristi to stejně nebudou používat. Ale co, kdo si hraje, nezlobí.

[megi]

Ano samozřejmě. Ještě jsi zapoměl, že to nepujde zkompilovat a když už ano, tak to nepůjde spustit. :)

[unchallenger]

Zkompilovat a spustit to možná půjde. Ale nepůjde z toho udělat balíček ;-)

[megi]

To je fakt. To ani není cílem. (viz. požadavky) :)

[Triton]

Část příspěvku byla asi reakcí na mě

Jen detail: removepkg timestampy nekontroluje. Nebo to aspoň v tom bordelu nemůžu najít.

delete_files() {
 while read FILE ; do
  if [ ! -d "$ROOT/$FILE" ]; then
   if [ -r "$ROOT/$FILE" ]; then
  if [ "$ROOT/$FILE" -nt "$ADM_DIR/packages/$PKGNAME" ]; then  
     echo "WARNING: $ROOT/$FILE changed after package installation."
    fi
    if [ ! "$WARN" = "true" ]; then
...

Ano. Minimálně dvakrát. Jednou test integrity, podruhé rozbalení /install ...

Rozbalení jako extrakce obsahu archivu do filesystému se opravu provede jen jednou a využije se cache z předchozího "rozbalení v paměti" při testu integrity. Ale to je přece nutné. Přece se nebude naslepo rovnou provádět instalace, když může být nedokončena kvůli chybě v archivu. Sice by se trochu ušetřilo pokusným rozbalením do pomocného adresáře a v případě úspěchu pak přesunutím do kořene, ale přijde mi to jako zbytečná krkolomnost.
Jak jinak lze získat popisek balíčku, pokud není v externím souboru, pro jeho zobrazení před samotnou instalací, než extrahováním install/slack-desc ?
Jak už jsem psal, preferuji jednoduchost shellscriptu oproti rychlosti, vy zřejmě opak.

Ono je pěkné mít ls a grep, ale pak nemůžete čekat, že se dostanete u prohlížení balíčků pomocí pkgtool pod 40s při startu.

To jsem moc nepochopil. Např. (nekešované)

triton@darkstar:~$ time ls /var/adm/packages | grep python
python-tools-2.4.1-noarch-1
python-2.4.1-i486-1

real    0m0.032s
user    0m0.016s
sys     0m0.006s

triton@darkstar:/var/adm/scripts$ time grep -lr usr/bin/nmap /var/adm/packages
/var/adm/packages/nmap-3.81-i486-1

real    0m0.028s
user    0m0.013s
sys     0m0.013s

Váš entuziasmus obdivuji a <nezprofanovaně>upřímně</nezprofanovaně> přeji úspěšné dotažení nápadu k cíli.

Happy coding

[Triton]

Ještě doplním:

triton@darkstar:~$ ls /var/adm/packages|wc -l
459
triton@darkstar:~$ du -s /var/adm/packages
15092    /var/adm/packages
dunric@darkstar:~$ 

P-M/600

[megi]

Jo jo, byla to reakce na vás. :)

Pokud chcete zobrazit všechny balíčky v menu: x 500 = 16 seknud. (minimálně, něco ještě sežere režie shellu)

Toho timestampu jsem si nevšiml.

Cache využije, ale pro zabalený archiv, takže dekomprese se provádí stejně dvakrát.

[megi]

Tak jsem se díval podrobněji na archivy několika balíčků a zjistil jsem, že s železnou pravidelností je slack-desc až jako úplně poslední soubor v archivu. To znamená, že gzip -d se provádí 3x vždy na celý soubor.

Zajímavé.

[Triton]

Pokud chcete zobrazit všechny balíčky v menu: x 500 = 16 seknud. (minimálně, něco ještě sežere režie shellu)

Na pkgtoolu jsme se shodli. Já se snažil ukázat, že zobrazení všech 459 balíčků standardními nástroji trvá zlomky vteřin.

Tak jsem se díval podrobněji na archivy několika balíčků a zjistil jsem, že s železnou pravidelností je slack-desc až jako úplně poslední soubor v archivu. To znamená, že gzip -d se provádí 3x vždy na celý soubor.

Pokud má tar v parametru místo seznam adresářů, přidává na dané úrovni jeho obsah reverzně. Sám nevím, proč tomu tak je.

To, na jaké pozici v taru se nachází slack-desc nebo jakýkoli jiný soubor přece nemá vůbec žádný vliv. Pokud chci cokoliv z tgz vyextrahovat, vždycky se prvně provede kompletní dekomprese gzipem.

Minule jsem souhlasně uvedl, že v installpkg je teoreticky prostor pro optimalizaci, kdy by se s jedním rozbalením vystačilo. Přibyl by ale mezikrok pro přesun z dočasného do kořenového adresáře, resp. úklid po narušeném archivu. I tak by to bylo sice rychlejší, ale přijde mi to méně elegantní řešení bez valného přínosu. Nebo vás napadá ještě jiný elegantnější nebo rychlejší algoritmus ?

Zkusil jsem si změřit čas testu a čas extrakce velkého tgz archivu(cca 60MiB) a test byl o 1/2 - 2/3 kratší (fs ext3, noatime).

[megi]

To, na jaké pozici v taru se nachází slack-desc nebo jakýkoli jiný soubor přece nemá vůbec žádný vliv. Pokud chci cokoliv z tgz vyextrahovat, vždycky se prvně provede kompletní dekomprese gzipem.

Má. Jakmile vyextrahuje ty soubory, které jsou požadovány, tak končí a dál nečte.

Zkusil jsem si změřit čas testu a čas extrakce velkého tgz archivu(cca 60MiB) a test byl o 1/2 - 2/3 kratší (fs ext3, noatime).

To je jasné.

[Triton]

... je slack-desc až jako úplně poslední soubor v archivu. To znamená, že gzip -d se provádí 3x vždy na celý soubor.

To, na jaké pozici v taru se nachází slack-desc nebo jakýkoli jiný soubor přece nemá vůbec žádný vliv. Pokud chci cokoliv z tgz vyextrahovat, vždycky se prvně provede kompletní dekomprese gzipem.

Má. Jakmile vyextrahuje ty soubory, které jsou požadovány, tak končí a dál nečte.

Docela mě to překvapuje, ale asi nechápete základní strukturu tgz archivu. Všechny soubory jsou přidány do jednoho taru a tento archiv je potom jako jeden soubor komprimován např. gzipem, tj. vaše dedukce: slack-desc je na konci taru => gzip -d se musí provést na celý soubor, je chybná. To umístění má vliv až na druhou fázi, tj. rozbalení samotného taru.

[megi]

Ne. Tar spouští gzip -d a po kouscích (třeba 16k) si od něj bere rozbalená data a na nich dělá další zpracování (dekódování hlaviček, ukládání dat do souborů). Jakmile ze streamu získá všechny soubory, které se od něj chtějí, tak končí. Takže pokud jsou data až na konci, archivu tak musí prolézt celý archiv. Pokud jsou na začátku, tak je načte a zbytkem se vůbec neobtěžuje.

Teď to zkouším a koukám, že to GNU tar takhle nedělá. Žádný program není dokonalý. :) Takže se vždy musí dekomprimovat třikrát celý soubor.

Nicméně to je stejně divné, dávat soubory, které potřebuji z archivu rychle dostat až na konec.

[Triton]

Teď to zkouším a koukám, že to GNU tar takhle nedělá. Žádný program není dokonalý. :) Takže se vždy musí dekomprimovat třikrát celý soubor.

Jsem rád, že jste si to moje tvrzení ověřil

Třeba vás to bude inspirovat k napsání vlastní implementace taru

[megi]

Díky tomu, že to archiv proleze celý, tak už by mohla být další kontrola zbytečná. Takže možná že i tak by šlo installpkg zoptimalizovat alespoň trochu.

Mimochodem: Už se stalo. :)