spkg

14.6.2005 16:00 | Přečteno: 1148× | Slackware

Tak už mě přestalo bavit (ne že by mě to tedy někdy bavilo ) čekat na instalaci a hlavně upgrade balíčků pomocí pkgtools.

Jinak je Slackware moc pěkná distribuce, ale ten balíčkovací manažer, to je fakt bída. Kdo viděl obsah skriptu removepkg, musí uznat že pokusy o optimalizaci pro rychlost v bashi nevypadají příliš vábně a v případě removepkg nejsou ani příliš úspěšné. O robustnosti se netřeba vůbec bavit, když něco selže (třeba user udělá z dlouhé chvíle ctrl+C při upgrade glibc) je po srandě. Vůbec spuštění removepkg, když zrovna data nejsou v cache je taky zážitek. Installpkg rozbaluje archiv úplně zbytečně dvakrát, upgradepkg jakbysmet. Prostě bída.

Funkce zobrazení nainstalovaných balíčků pomocí pkgtool je taky kapitola sama pro sebe. Kolika lidem už zešedivěly vlasy při sledování tohoto nápisu - Please wait while Pkgtool scans your system to determine which packages you have installed and prepares a list for you. Operace, která by měla trvat pár milisekund, trvá na 1.5GHz Pentiu 4, světe drž se, 40 sekund!

O nějakém smysluplném rozhranní (API) pro přístup k databázi balíčků v rámci systému si člověk také může nechat leda zdát.

Tak jsem se s tím před dvěma měsíci rozhodl něco udělat a začal reimplementovat pkgtools v C.

Příště napíšu více. Zatím dávám jen odkaz na stránky s projektem.

       

Komentáře

[iSteve]

Timpadem bych te rad upozornil na muj projekt, UPKG: http://web.isteve.bofh.cz/upkg/ ;)

[megi]

Už jsem měl tu čest vidět. :)

[unchallenger]

Nechtěli byste raději vypnout v RPM závislosti (nebo v dpkg, to je jedno) a začít ho používat? Tyto věci už jaksi byly vyřešeny.

[VícNežNic]

Ještě by bylo fajn, aby ty balíčky nebyly všechny tak rozkouskované

[Michal Marek (twofish)]

Na co by pak nadávali?

[unchallenger]

Přece na RPM! Konečně by k tomu měli i pořádný důvod ;-)

[Triton]

• 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ý.
• 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é.
• 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.
• 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.
• 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
• 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.

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.

Happy buffer overflows

[unchallenger]

Dokonce ty, které používají k evidenci instalací databáze místo prostých textových souborů, bývají daleko náchylnější.

Pak používají ty databáze blbě. Skutečnost, že obyčejný souborový systém neumožňuje atomické commity, kdežto databáze ano, to nemění. Glibc sama se snad upgraduje atomicky všude, to nemá smysl řešit.

Happy buffer overflows

Berkeley DB je odladěná přinejmenším stejně dobře jako grep (v tom už jsem našel chybu).

[Triton]

No ono to možná nebude tak jednoduché. Mám zkušenost, kdy při upgrade jednoho stroje se SUSE došlo k výpadku napájení (vím, ostuda že nebyl na UPS) a po rebootu se zjistilo že rpm databáze je pr... Domníváme se, že za to sice nemůže databáze samotná, ale jak došlo při commitu k výpadku, tak ten journal se nějak poškodil (chybou fs ?) a bylo to v trapu. Navíc nejde jen o mechanismy zajišťující integritu databází, ale o prostý fakt, že jsou db jako způsob uložení dat komplikovanější a i třeba chybou sw, který do nich uloží špatný záznam, se daleko hůře rekonstruují.

No následky chyby v BDB, kam se data zapisují a závisí na ní např. celý systém, s následky ekvivalentních chyb v grepu, jako nevinného nástroje k vyhledávání, bych raději nesrovnával

Jinak to Happy buffer overflows bylo spíš myšleno jako lehká narážka na to, že to chce implementovat v "náchylném" C místo "méně náchylného" shellu nebo jiného interpretu

[Michal Marek (twofish)]

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.

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.

[Triton]

Asi to bude tím, že jsem minimalista a purista

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.