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 :-D

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.