spkg podruhé

15.6.2005 15:22 | Přečteno: 1082× | Ostatní

Můj první příspěvek vyvolal několik kritických reakcí, za což vřele děkuji. Kritika je vždycky potřeba. Minule to byl jen takový nástřel mé nespokojenosti s pkgtools. Dnes napíšu o tom co by mělo a co by nemělo být spkg a odpovím na některé připomínky z minula.

O čem to je?

Slackware používám hlavně kvůli jednoduchosti jeho balíčkovacího systému a jeho minimalističnosti. To je pro mě hodně důležité, protože já balíčkovací manažer využívám velmi často a způsoby kdy potřebuji poměrně dobře vědět co všechno dělá a aby to dělal co nejrychleji. (přiznávám, že nejsem asi nejlepším příkladem typického usera)

Nenechte se zmílit, koncept pkgtools se mi velmi líbí. Pkgtools mají jako nízkoúrovňové nástroje všechny funkce které potřebuji - instalalce, upgrade a odinstalace. Tím nízkoúrovňové myslím to, že se nestarají o nic jiného než o udržování seznamu nainstalovaných balíčků a k nim patřících souborů.

O čem to není?

Ne opravdu to není o reimplementaci funkcí RPM, či DPKG. Či jiných pododbných oblud (co do velikosti kódu a množství funkcí). Mým cílem naopak je, aby to co do velikosti kódu a funkcí bylo srovnatelné s původními shellovými skripty.

Vady na kráse pkgtools - z mého pohledu :)

• Hlavní vadou jsou závislosti. Pkgtools potřebují nějaký shell.
• S shellem souvisí další nevýhoda, taková reinstalace (ne upgrade, to je ještě daleko horší!) gaimu (4.5MB) potřebuje 561 forků. No a stou zase další...
• Na 1GHz athlonu to trvá 12s - a to musí být všechna potřebná data v cache - pokud nejsou, tak to trvá kolem 40s.
• Rychlostní limit, kterého by se dalo dosáhnout při upgrade je na stejném stroji 0,6s. Tolik totiž trvá tar xzf.
• Chybí librifikace funkcí balíčkovacího mamanžeru, která by se určitě hodila někomu kdo by chtěl napsat nějaké uživatelské rozhraní, nebo rozšířit funkce balíčkovače o kontrolu integrity nainstalovaných balíčků, nalezení souborů v /usr, které nepatří k nainstalovaným balíčkům, atd. atp.
• Současné pkgtools nemají funkci pro zjištění toho, co v systému přepíší. -warn je k ničemu, protože ukazuje všechny instalované soubory, i pokudv systému neexistují.

Jaký je můj cíl?

Hlavní cíl je zrychlení. U instalace lze dosáhnout zrychlení 2x-3x, u upgrade 6x-10x, u odstraňování 10x-20x. Dalším cílem je kompatibilita se stávajícími pkgtools. Tedy stejný formát databáze. Minimalizace závislostí. No a nakonec librifikace všech činností balíčkovače (včetně přístupu k databázi) a kvalitní dokumentace.

K připomínkám z minula

Instaluju a upgraduju i na "šunkách" P/166 64MB a nikdy jsem problémy s rychlostí neměl a navíc čas instalací z celkového času využití počítače je naprosto zanedbatelný.

Taky občas instaluju na jedné šunce: 486/50Mhz/16MB. :) Ne, ale o tom to není. Já si udržuju vlastní živou distribuci, takže sem tam potřebuju udělat "plnou" instalaci do ROOT=/livecd, takže zrychlení 2x-3x by občas nebylo vůbec na škodu. Jsou prostě lidi, kterým se rychlý b.m. může hodit.

Removepkg mi jako shellscript nepřijde zbytečně pomalé. Před smazáním souboru nebo adresáře se provadí docela dost testů (jestli není obsažen v jiném balíčku, podle timestampu jestli byl změněn, jestli adresář, který byl balíčkem vytvořen neobsahuje nové soubory, generování seznamu linků vytvořených z instalačního skriptu, atd.). Nic z toho mi nepřipadá zbytečné a zjevně špatně optimalizované.

Na shellscript to možná pomalé není, ale pokud lze udělat ony testy duplicit a generování seznamu linků tak, že třeba pro balíček s 5000 soubory to na systému, kde je 150 000 souborů lze stihnout za 5ms, tak proč to tak nedělat? Jen detail: removepkg timestampy nekontroluje. Nebo to aspoň v tom bordelu nemůžu najít. A hlavně mě nejde do hlavy s čím by je asi porovnával, když si je neukládá do databáze.

Installpkg rozbaluje archiv dvakrát? Na začátku pouze rozbalí obsah instalačního adresáře, když nemůže najít popisný externí soubor. Také testuje integritu archivu (-tzf) a pak ho teprve jednou rozbalí. Proč je tam ta extrakce popisku balíčku snad nemusím vysvětlovat.

Ano. Minimálně dvakrát. Jednou test integrity, podruhé rozbalení /install (tady záleží na tom kde se v archivu adresář /install nachází což je díky tomu že začíná na "i" naštěstí před /usr a /opt, takže to není až zas tak strašné) a napotřetí naostro.

Přerušení při instalaci glibc aj."páteřního" sw, ať už zdůvodu hw problémů nebo interaktivně, bývá věc fatalní, ale to platí stejně pro všechny mě známé způsoby instalací. Dokonce ty, které používají k evidenci instalací databáze místo prostých textových souborů, bývají daleko náchylnější. A obnova se může snadno řešit použitím rescue CD. U instalace ostatních balíčků to nevadí. Navíc bych chtěl vidět "usera", který instaluje glibc Ale vy jste asi myslel toho s uid 0.

Samozřejmě. Pravděpodobnost selhání ovlivnit nemůžeme. Co ale můžeme ovlivnit je délka doby, kdy selhání může vést k destrukci systému. Ovlivňuje je délka "ostrých" operací na databázi a hlavně délka doby po kterou jsou na souborovém systému promíchány soubory starého a nového balíčku. A tato doba se dá velmi rapidně zkrátit pomocí způsobu, který se chystám v následujícím týdnu naprogramovat. V současnosti pkgtools dělají to, že nechávají tar přepisovat staré soubory postupně tak jak jsou rozbalovány nové. Je jasné že přerušení upgrade povede k problémům. Ať už přijde odkudkoliv.

Souhlas, pkgtool je hlavně pro zobrazení nainstalovaných balíčků nepoužitelný. Nevím k čemu tam je, protože není nad ls, grep a less. Snad možná kvůli newbies, kteří se trochu bojí CLI

To je pěkné, ale právě noobs potřebují např. krátký popis balíčku, díky jehož získávání je to jak šnek.

API k přístupu k databázi balíčků? Si děláte srandu? Jukněte se do /var/log/packages|scripts|removed_packages|removed_scripts . Pak na ls, grep a další základní unixovské nástroje a možná vás už ta otázka znovu nenapadne.

Si srandu nedělám! :) Teď trochu vážně. 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. LOL

Přeju vám hodně úspěchů s realizací vašeho projektu a také hodně nespokojených uživatelů oficiálních balíčkovacích nástrojů, kteří by měli potřebu používat něco jiného. Já mezi nimi nebudu, protože filozofie administrativních nástrojů u Slackware, tj. co nejprimitivnější a nejpřímější, mi zcela vyhovuje i za cenu, že nepoběží tak rychle, jak by teoreticky mohly. ... S tím příkladem k /etc/group máte pravdu, ale já to chápu tak, že to je už dlouho zavedený způsob snad na všech *nixech co znám nebo o nich četl a filozofií Slackware je, že pokud to není nezbytně nutné, tak se právě snaží nepřidávat žádné svoje specialitky, jako je tomu často vidět u některých dister. Ale respektuju, že někomu jinému tento přístup nevyhovuje nebo na to dokonce kašle.

No já na té primitivnosti, jak jste již poznal nic měnit nechci (dokonce ani nahrazovat původní databázi balíčků). Jediné co chci je rychlost. Takže ještě uvidíme. Osobně mi bude stačit úplně jeden spokojený uživatel, a to já. :)

Happy buffer overflows

Tak z toho už jsem naštěstí vyrostl. :)

Nemít žádnou úroveň abstakce vede k ... tedy vlastně nikam nevede, protože to neumožňuje jakkoliv měnit implementaci. Proto existují API i k takovým trivialitám jako /etc/group.

Přesně! Navíc to jak to dělám já umožní zároveň používat všechny existující nástroje které používají originální databázi balíčků a zároveň do databáze ukládat další data (kontrolní součty, práva k souborům, cokoliv).

Příště?

Příště se rozepíšu více o způsobu implementace.

       

Komentáře

[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. :)