Pacman pro ArchLinux a co mi na něm vadí

24.4.2007 16:12 | Přečteno: 3573× | Unix, Linux, ArchLinux |

Poslední dobou se zde na ABCLinuxu objevil druhý díl velmi zdařilého seriálu o balíčkovém systému ArchLinuxu. Přestože používám téměř výhradně ArchLinux, mám k jeho balíčkovému systému hned několik vážných výhrad. Také zde nastíním některé možnosti řešení těchto problémů, ač ne vždy realizovatelné.

Trocha kritiky aneb Co se mi nelíbí

Veškeré níže zmíněné problémy jsem již popisoval v diskusním příspěvku k prvnímu dílu seriálu. Dal jsem si na tom příspěvku záležet. (A přiznávám, že byl nepříjemně dlouhý.) Potom se ale ozvalo ŽUCH a můj příspěvek vzal za své. Proto jsem se rozhodl vše popsat ještě jednou a podrobněji.

Nepřehlednost zdrojového kódu

Zkuste si někdy jen tak pro zajímavost přečíst kousek zdrojového kódu pacmana. Je to zajímavý zážitek. Najdete tam na mnoha místech například čtyři úrovně vnořených for-cyklů. Kromě peprných poznámek o efektivitě takového řešení vás jistě napadne, zda by nebylo záhodno pomýšlet na trochu lepší dekompozici celého úkolu. V tomto názoru vás nejspíš utvrdí fakt, že některé funkce mají délku až 500 řádků - téměř bez jediného komentáře, který by nezúčastněnému čtenáři (programátorovi) dával smysl.

Všechno má samozřejmě své příčiny. Pacman v raných verzích ArchLinuxu existoval ve formě sady skriptů pro bash a Perl. Většina systémových utilit existovala původně jen v této formě. Teprve potom vznikaly binární verze přepsáním některých skriptů do C. Bohužel toto řešení nebylo příliš šťastné, jak nastíním dále.

Jistě je rozumné se domnívat, že by někdo chtěl v budoucnu pro pacman vyvinout například různá rozšíření či moduly a že taková rozšíření mohou být jednou potřebná. Při současném stavu zdrojových kódů však nelze na něco takového vůbec pomýšlet.

Efektivita - ajéje!

Ta je zkrátka a jednoduše bídná a těžko se pro to hledá omluva. Nejde tu totiž o nejlepší nebo nejsložitější balíčkový systém. Kromě již zmíněného nešťastného stylu zdrojového kódu, o jehož efektivitě lze silně pochybovat, je příčinou též samotný způsob uložení dat.

Pacman ukládá svá data v podivné adresářové struktuře ve /var/lib/pacman. Možná nebudu daleko od pravdy, když vyslovím domněnku, že tato struktura je pozůstatkem z „období skriptů“, který byl zachován kvůli kompatibilitě. Manipulace s touto strukturou je extrémně neefektivní.

Slyšel jsem i názory, že pacman bude fungovat lépe na ReiserFS, který rychleji manipuluje s malými soubory. Bohužel s tím nemohu souhlasit. Na mém stroji běží stejně bídně na ReiserFS i na ext3. Návrh na umístění databáze pacmana na loopback do souboru je taktéž zajímavý, ale nejde o řešení původního problému. V běžných souborových systémech je vždy první dotaz zoufale pomalý a teprve opakované dotazy, při kterých už se využívá disková cache, fungují obstojně.

Velmi rád bych zdůraznil, že problém zdaleka není jen v pomalých diskových operacích. Na starém počítači (233 MHz, 256 MB RAM) trvala příprava k aktualizaci systému, tedy porovnání verzí a nalezení zastaralých balíčků, cca 45 minut, bez jakékoliv nadměrné diskové aktivity. Něco takového je (mírně řečeno) nepřijatelné.

Možnosti a funkce

Ani tady nelze říct, že by bylo vše v pořádku. Chybí mi především funkce pro kompilovaný update. Ten může být potřebný z několika důvodů.

• Portovatelnost. Zatím existuje pouze port na AMD64. Ve srovnání s Gentoo a Debianem není situace ArchLinuxu v této oblasti dobrá. Spolehlivě fungující kompilovaný update by ArchLinux zpřístupnil i pro platformy, pro které není k dispozici aktualizovaná binární repository.

• Vlastní nastavení kompilátoru. Nastavení pro konkrétní procesor může znamenat hodně. Například na mém notebookovém chipsetu Intel se sdílenou pamětí se po překompilování X-serveru zvýšil framerate u 3D aplikací až o třetinu. Snížení doby bootování o 10% taktéž nebylo k zahození.

• Použití alternativního kompilátoru. Přestože od doby Pentia II mají všechny procesory vektorové instrukce, kompilátory je neumí používat. Kompilátor Intel pro procesory Intel je jednou ze světlých výjimek. U některých pokusů s poli jsem naměřil až čtyřnásobný rozdíl v čase výpočtu. Protože však kompilátor Intel není svobodný software, nelze balíčky jím kompilované volně zveřejnit.

Pro kompilaci balíčku existuje adresářový strom ve /var/abs a shellový skript makepkg, který každý balíček vytvoří pomocí souboru PKGBUILD. Pro rekurzivní průchod stromem balíčků a kompilaci celého podstromu slouží skript makeworld.

Tyto dvě možnosti ale zdaleka nejsou dostačující. Oddělená kompilace jednoho balíčku je sice dobrým řešením, pokud neexistuje jeho binární forma a je k dispozici jen PKGBUILD. V ostatních případech je ale poněkud samoúčelná, ne-li nevhodná, protože může nastat případ, že spolu s balíčkem nebudou aktualizovány balíčky, které na něm závisí. Jde-li o sdílenou knihovnu, u níž došlo ke změně API, dostaneme nekonzistentní stav.

Kompilace celého podstromu balíčků je dobrá pouze a výhradně pro správce repository. V jiných případech nemá smysl, protože podstrom se samozřejmě nekryje s balíčky nainstalovanými v daném systému. Proto nejde o kompilovaný update. Napřed by člověk musel mít skript, který projde celý strom abs a smaže adresáře nepoužívaných balíčků.

Zásadním problémem je správné dodržení závislostí při aktualizaci. Jakmile provádíme binární update, spoléháme na kompetentnost a odpovědnost správce repository. Kompilovaný update ovšem vyžaduje rekurzivní průchod stromem build-time závislostí. V drtivé většině případů se nemění API knihoven a je tedy málo pravděpodobné, že by došlo k potížím. Spokojíme-li se s tímto chabým ujištěním, lze dnes celý systém aktualizovat například takto:

#!/bin/bash

pacman -Sy
abs

TO_UPDATE=`{ pacman -Q; echo ---; pacman -Sl | cut -d' ' -f2,3; } | \
awk '
BEGIN { ORS = " "; }
/^---$/ { all = 1; }
{
        if ( all ) {
                version = installedArray[ $1 ];
                if ( version ) {
                        ( "vercmp " version " " $2 ) | getline result;
                        if ( result < 0 ) { print $1; }
                }
        } else {
                installedArray[ $1 ] = $2;
        }
}'`

cd /var/abs
for NAME in $TO_UPDATE; do
        ( cd `find -name "$NAME"`; makepkg -bcr )
done

pacman -Scc
makepkg -C
cd /var/abs && rm -R *

Je nutné mít správné nastavení v souborech /etc/abs/abs.conf a /etc/makepkg.conf. Tento skript aktualizované balíčky pouze zkompiluje a neinstaluje. Pro současnou instalaci stačí přidat -i do argumentů makepkg.

Problém rozšiřitelnosti

V současném stavu rozhodně není možné pomýšlet na různá rozšíření pro pacman. Jeho celková koncepce to zkrátka neumožňuje. Já si ovšem umím představit spoustu užitečných možností rozšíření, které by jistě vedly k lepší použitelnosti.

• Režim klient/server. Tady by šlo spíš o přepsání from scratch než o rozšíření, ale i přesto si myslím, že něco takového je nezbytné. Už kvůli tvorbě různých front-endů. Umím si představit (navzdory velmi odmítavým stanoviskům autorů ArchLinuxu) grafického klienta pro pacman.

• Distribuovaná kompilace balíčků. Tak trochu souvisí s předchozím bodem. Dejme tomu, že je laboratoř plná nestandardních strojů. Ty by mohly používat ArchLinux, pokud by byla rozumně zajištěna instalace a aktualizace. Toho by bylo možné docílit právě pomocí distribuované kompilace.

• Podpora pro sdílené síťové služby. Co třeba získávat binární balíčky přes BitTorrent, když už musí být binární? Nebo přes jinou síť? Zkrátka a dobře: Přehledné a modulární uspořádání by mělo své výhody.

Řečí plno - a jaké je řešení?

Nápad, na kterém je postavený ArchLinux, se mi velmi zamlouvá. O jeho implementaci však bohužel nemůžu říct totéž. Proto bych rád v krátkosti shrnul svou představu o návrhu a fungování balíčkového systému. Každý problém, o kterém jsem dosud psal, jistě má své řešení. Otázkou však zůstává, jak velké úsilí by bylo nutné vynaložit.

Modulární návrh a rozšiřitelnost

Základní návrh by měl počítat s co největší modularitou při zachování rozumné efektivity. Měl by poskytovat jen nejzákladnější funkce. Na něj by bylo možné navázat mnohá další rozšíření. Následující výčet je sice jen čirá fantazie, ale s takovým uspořádáním by byl správce balíčků mnohem použitelnější.

• Backend pro vzdálené soubory. Umožňoval by získání požadovaných souborů z Internetu. Měly by existovat backendy pro nejrůznější síťové služby od klasických až po peer-to-peer sítě, vhodné pro velké soubory.

• Backend pro databázi. Umožňoval by efektivní ukládání metadat pacmanu. Měly by být podporovány různé druhý databází, od embedded (možná přímo v backendu) až po větší databázové stroje. Když už například na serveru běží databázový stroj, není důvod jej nevyužít také ke správě balíčků.

• Backend pro repository. Umožňoval by správu a vytváření místních i vzdálených repository a získávání dat z nich. Měla by existovat podpora i pro jiné druhy repository než ten současný.

• Frontend pro uživatelské rozhraní. Celý pacman by mohl fungovat jako démon stahující a sdílející (podle přesných nastavení) balíčky. Frontend by mohl mít jakoukoliv podobu. Mohly by existovat frontendy pro vzdálenou správu přes webové rozhraní, různá grafická udělátka nebo prostě jen textoví klienti podobní dnešnímu.

Zmíněný výčet samozřejmě není zdaleka přesný a kompletní. Chtěl jsem jen docílit co největšího kontrastu se současným (téměř) monolitickým návrhem. Šíření balíčků pomocí peer-to-peer sítí mi připadá jako velmi příjemná alternativa k centrálním repository.

Přehlednost a jednoduchost

Zdrojový kód by měl být výsledkem spolupráce a diskuse několika autorů. V současné situaci tomu tak není a výsledek tomu odpovídá. Tak složitý systém jako správce software by měl mít vlastní dobře udržovanou webovou stránku. Neuškodil by taktéž coding style a dobře udržovaný systém komentářů.

Součásti implementované pouze jako skripty by měly být pokud možno eliminovány. Vše by mělo být konzistentní, zejména pokud jde o možnost sdílení modulů pro různé speciální funkce.

Nejsem sice fanatikým OOPákem, který nosí v kapse seznam Design Patterns, ale myslím si, že základy software tohoto typu by měly být založené na objektovém návrhu. Totéž samozřejmě nelze tvrdit o různých backendech. Jinde by ale použití C++ skutečně neuškodilo, spíš naopak.

Kdo by měl tohle všechno udělat?

Jestli jste dočetli až sem, gratuluji. Nepočítal jsem s tím, že někdo tento můj výlev vydrží číst. Zásadním změnám k lepšímu, pokud jde o rozšiřitelnost a efektivitu pacmana, stojí v cestě důležitý fakt: Tvůrci distribuce by stěží připustili existenci alternativního správce balíčků a založení nové distribuce je velmi špatný nápad.

Nabízí se tedy otázka, proč jsem celý tento blogpost napsal. Odpověď je snadná: Protože jsem už dlouho uvažoval o vytvoření nového balíčkového systému a protože mi trochu vadil poněkud nekritický přístpup některých uživatelů k pacmanovi.

Tak velké softwarové dílo jako správce balíčků rozhodně není úkolem pro jednoho člověka. Kromě toho mám náročnou školu a asi bych neměl dost odvahy se do něčeho takového pustit zcela sám.

Věřím však, že existuje spousta lidí, kteří se už podobnou myšlenkou zabývali a kteří by případně měli zájem na podobném projektu pracovat. Je-li tomu skutečně tak, rád a bez váhání bych se k této práci přidal.

       

Komentáře

[cezz]

To peer-to-peer mi pripomenulo jeden moj starsi zapis o gentoorrent.. :)

Nieco podobne ma napadlo aj nedavno, ked boli po release Ubuntu 7.04 nenormalne vytazene repository.

[Michal Vyskočil]

Protože však kompilátor Intel není svobodný software, nelze balíčky jím kompilované volně zveřejnit.

Myslím, že s takovými licenčními podmínkami by Intel nevydělal ani na suchý chleba .

[Andrej]

Možná, ale neplacená verze kompilátoru je výhradně pro nekomerční použití. Proto si myslím, že není možné, aby například Novell bez následků vydal své SUSE s X-serverem zkompilovaným kompilátorem Intel. Musel by nejspíš zaplatit nemalé licenční poplatky.

Pokud by nebyly podmínky tak přísné, proč už např. pro ArchLinux nikdo nevytvořil alternativní repository s balíčky kompilovanými kompilátorem Intel nebo Sun? Kromě toho se bohužel pořád ještě nedá zkompilovat samotný Linux ničím jiným než GCC, takže možnost alternativních kompilátorů je zatím ve hvězdách.

[Michal Vyskočil]

OK, ale o neplacené verzi icc v zápisku není ani slovo

Navíc, těch pár set dolarů za linuxovou verzi překladače by takový Novell asi nezabilo. Spíš by mě zajímalo, jak takový Intel-optimized kód běží na procesorech AMD?

[Max]

Spíš by mě zajímalo, jak takový Intel-optimized kód běží na procesorech AMD?

Dobrej joke... :D
Zdar Max

[Andrej]

Firma AMD má samozřejmě možnost vytvořit a vydat svůj překladač, stejně jako to dělá Intel. Nevidím důvod, proč by měl kód z překladače Intel běžet dobře na AMD. Protože můj počítač má procesor Intel, zajímám se pochopitelně o Intel víc než o AMD a jejich kompilátor byl první z alternativ, která mě napadla.

[Trained.Monkey]

Pred par dny jsem presel na Ubuntu, jinak bych si mozna dal rict na prepsani pacmana

[Andrej]

No jo, já se asi jednou naštvu a přejdu na OpenSolaris...

[Dunric]

Administrativní nástroje by IMHO neměly být v nativním kódu. Přímá závislost na nainstalovaných systémových knihovnách a kontrola/udržba kódu v něčem jako je C je daleko náchylnější k problémům než když to poběží v shellu nebo třeba interpretru Pythonu. U těchto programů není prioritou rychlost, proto je vývoj v nízkoúrovňových jazycích zbytečná komplikace. Pokud něco trvá neúměrně dlouho, je většinou problém v použitém algoritmu nebo např. už zmíněném nevhodném způsobu ukládání dat a přístupu k nim.

Výjimkou potvrzující pravidlo mohou být dpkg/APT z Debianu

Btw. dělá Pacman pořád tu prasárnu, že přepisuje po upgradu balíčků jejich konfigurační soubory, přestože jsou v nich provedené změny ? Musí se stále explicitně uvádět v pacman.conf aby se nepřepsaly ?

[Ondrej 'SanTiago' Zajicek]

Administrativní nástroje by IMHO neměly být v nativním kódu. Přímá závislost na nainstalovaných systémových knihovnách a kontrola/udržba kódu v něčem jako je C je daleko náchylnější k problémům než když to poběží v shellu nebo třeba interpretru Pythonu.

Zavislost takoveho programu napsaneho v C je minimalni - typicky libc a a par dalsich knihoven. Program v perlu nebo pythonu zavisi na interpretu, (ktery sam je typicky napsany v C a ma tedy podobne zavislosti na systemovych knihovnach), na pouzivanych knihovnach a na bindings tech knihoven do interpretovaneho jazyka. Tedy zavislost v pripade interpretovaneho jazyka bude typicky vetsi.

[Dunric]

Myslel jsem přímou závislost. Takový bashový nebo pythonní skript je "odolnější" vůči updatům interpretrů než (g)libc nejenom v rámci major verzí, jinými slovy po upgradech pravděpodobněji poběží bez nutnoti změny kódu. Nemohu a IMHO to ani nelze dokázat, toliko moje osobní zkušenosti.

[Andrej]

Btw. dělá Pacman pořád tu prasárnu, že přepisuje po upgradu balíčků jejich konfigurační soubory, přestože jsou v nich provedené změny ? Musí se stále explicitně uvádět v pacman.conf aby se nepřepsaly ?

Pokud je balíček správně nastaven, nemělo by se to stát a konfigurační soubory by se měly uložit s příponou .pacnew při aktualizace a .pacsave při odstranění. Jestliže však balíček tuto informaci v sobě nenese, ani nejlepší pacman to nezachrání.

[pholie]

Umím si představit (navzdory velmi odmítavým stanoviskům autorů ArchLinuxu) grafického klienta pro pacman.
to ja tiez. zopar ich existuje, ale tie iba parsuju textovy vystup pacmana. pacman 3 je uz rozdeleny na kniznicu a klienta, tak casom snad vzniknu nejake normalne graficke frontendy

Co třeba získávat binární balíčky přes BitTorrent, když už musí být binární? Nebo přes jinou síť?
vo verzii 3.1 vraj nieco take planuju. niekde v mailing liste to bolo

inak so zvyskom clanku suhlasim

[dvh]

Vdaka za tvoj podnetny blog, prave si pisem vlastny balickovaci system takze sa mi to zijde.

[vogo]

To by bylo abych se nevyjádřil :), zdrojový kód pacmana myslím znám velmi dobře, jak verzí 2.9.x tak verzí 3.0.x. Vezmu to popořadě :)

Nepřehlednost zdrojového kódu

úplně první verze pacmana vyšla v roce 2002, a už tehdy byl pacman napsán v C (jinak když se lepil arch, tak to dělaly skripty v úplných začátcích). Přehlednost a jednoduchost, ovšem tehdy to byl jeden jediný céčkový zdroják + sada skriptů (makepkg a spol). Kvalita kódu není kdo ví jaká, ale trojka je o dost stravitelnější, ale hodně by se dalo zlepšit, velkoě prospělo oddělení backendu (libpacman), což umožňuje napsat alternativní frontendy. Co se týče komentářů v kódu, je to opravdu bída. Osobně nemám rád pluginovací systém, pokud něco chybí, měl by to nabízet nějaký skript, nebo by se to mělo doimplementovat do programu (viz pacman-color, jistě by to všechno šlo dělat důmyslným skriptem, nebo modulem, ale o dost jednodušší to bylo dodrátovat).

Efektivita - ajéje!

Efektivita se s přepsanou verzí zlepšila, ale vždy je co zlepšovat, hlavním cílem je jednoduchost, porovnejte si pacmanovský systém třeba s RPM (BTW podobné problémy s výkonem má třeba i portagetree). Jiank při přechodu na dvojkovou verzi se databáze konvertovala, a řekněme si na rovinu, kdyby byl velký tlak změnit systém ukládání informací, tak to byl ten pravý čas, nyní si musíme počkat, třeba na 4.0.0 :).

Uložení dat má své pro i proti. Pokud se něco nepovede, mohu to vždycky dát dohromady ručně. Pokud by se tato struktura ukládala do databáze (opravdové), bylo by to o dost složitější (BTW podobně to má i gentoo - z toho vyplývá neefektivita). Tento problém s výkonem tohoto řešení má i gentoo, je to tam na jedno brdo.

Možnosti a funkce

Portovatelnost: tým archlinuxu není kdo ví jak veliký, ale jistě Vás uvítají, pokud se nabídnete jako správce nové platformy, či kompilovaných updatů, BTW srovnávat Gentoo s binárními distry není na místě.

Vlastní nastavení kompilátoru: dost to souvisí s předchozím, jinak optimalizace jde nastavit v makepkg.conf. Nezapomínejte, že arch je binární, pokud chcete systém na míru je tu gentoo. BTW jak by jste chtěl tohle udělat třeba na manrdivě ;) nějak nechápu.

Použití alternativního kompilátoru: sám jste si odpověděl:) ale nic nikomu nebrání, aby vše upravil pro použití jiného, než svobodného kompilátoru. Pokud něco chcete, tak to udělejte, ostatní taky dělají vše za darmo (nebo za mrzký peníz), takhle prostě funguje komunita, já něco napíšu, ty něco napíšeš. remcaly nikdo nemá rád.

ABS

ABS je něco navíc oproti binárním distribucím, rozhodně to není věc určená pro kompletní překompilování systému, to dělá leda masochista. Podívejte se na archovskou wiki, ABS je určen hlavně pro kompilaci jednotlivých balíčků, u kterých vám chybí nějaká funkcionalita, ať už chcete přidat nějaký patch atd., prostě je to strom PKGBUILDů z oficiálních repositářů, nic víc nic míň. Pokud chcete překompilovat celý systém, je to váš rybíz, a opět řeknu, tak použijte gentoo, arch je binární distribuce.

Problém rozšiřitelnosti

Viz výše, jinak si myslím že grafický frontend je pro archlinux zbytečný, tahle distribuce se snaží být bez balastu, odpovědí je libpacman. Úplně stranou zůstává to, že banda vývojářů je trochu zabedněná :) (trochu víc).

Přehlednost a jednoduchost

Navenek je pacman jednoduše ovladatelný a přehledný, k tomu jak vypadá kód jsem se vyjádřil.

Kdo by měl tohle všechno udělat?

Ten kdo kritizuje? No dobrá, ale nebylo by od věci ze zapojit do mailinglistu. A jen tak stranou, pacmana nedělá jeden člověk, už dávno ne. Pokud vás něco štve, tak to zkuste napravit, a patch poslat vývojářům, asi se hned nepostaví kladně, ale pokud splníte jejich připomínky, je tu šance na změnu, viz můj patch ;).

[Andrej]

Nepřehlednost zdrojového kódu

Tak to je pozitivní zpráva, že dojde ke změnám. Kdysi jsem měl (nějakým zázrakem) trochu času a říkal jsem si, že bych třeba doplnil něco zajímavého do Pacmana. Nepočítal jsem s tím, že by to vývojáři ArchLinuxu přijali, ale prostě jsem si ho chtěl trochu vylepšit a dát to ostatním k posouzení. Bohužel k tomu nedošlo, protože pohled na zdroják mě vyděsil natolik, že jsem od svého záměru ustoupil. Možná se někdy vzchopím a pokusím se ho celý přečíst, ale nevím, kdy to bude.

Efektivita - ajéje!

Tlak na změnu databáze jistě není, protože se dělají rychlejší procesory a rychlejší disky a nikoho to nezajímá. Ale elegance se vytrácí. Pokud jde o tu databázi, jistě by byla zranitelnější než ta současná, ale uživatel by třeba mohl mít možnost volby, kterou chce použít. Proto jsem tolik mlel o těch backendech a modulech.

Možnosti a funkce

Kdysi dávno jsem Mandrivu měl a i tam byla možnost stáhnout balíček se zdrojovým kódem a nechat ho zkompilovat. Ne že by to vždy fungovalo a ne že by to bylo snadné, ale šlo to, dokonce přímo přes ty jejich příkazy urpmX. Pokud jde o portovatelnost, to byla spíš moje snaha zdůvodnit, k čemu je dobrý kompilovaný update i pro binární distribuce. Pro Mandrivu by to jistě k ničemu nebylo, ale tohle je jiný případ - ArchLinux je přece jen nízkoúrovňová distribuce. S tou správou platformy je to těžké, protože vlastním dva Intely a jinak nic. Spíš jsem se snažil zdůvodnit, k čemu by případně mohl být dobrý kompilovaný update.

Je mi jasné, že remcaly nikdo nemá rád, ale mým cílem nebylo remcat. Spíš jsem chtěl nenápadně pošťouchnout případné zájemce o tuhle problematiku a zjistit, zda by náhodou někdo neměl zájem spolupracovat na vytvoření nějakého balíčkového systému.

ABS

ABS je skvělý systém, který v podstatě každý týden používám na update systému pomocí skriptu, který jsem do blogpostu napsal. Pak mám ještě jiný, který do ABS nenápadně podstrčí moji vlastní konfiguraci kernelu, ale to už je zas jiná pohádka. Pro mě (a nejsem jistě sám) je ABS středobodem zájmu v této distribuci a rozhodně ho nepovažuji za okrajovou záležitost. Balíčky z AUR stahuji výhradně jako PKGBUILD, je-li dostupný.

Samozřejmě nepochybuji o tom, že ArchLinux se profiluje jako binární distribuce a že tato filosofie má spoustu výhod. Jenže mnou navrhovaný balíčkový manažer by se nejspíš zdaleka neomezoval jen na ArchLinux a jen na binární distribuce. Zatím je to samozřejmě jen pohádka, ale taková byla idea. Proto považuji za zcela přirozené, že by se měl umět správně vypořádat i s kompilací, včetně kompilovaného updatu.

Problém rozšiřitelnosti

Abych řekl pravdu, názor, že ten nebo tamten frontend je zbytečný, mi připadá poněkud příliš ortodoxní. Neříkám, že by měli vývojáři ArchLinuxu něco takového vytvořit, ale mám za to, že by časem takový frontend vznikl a rozhodně by nebyl ke škodě. Dokonce nevylučuju, že i já bych ho používal, pokud by byl dobrý.

Donedávna jsem byl odpůrcem grafických udělátek na instalaci software, ale vyzkoušení systému PC-BSD, který má krásného softwarového manažera integrovaného přímo do Ovládacího centra KDE mě přesvědčilo, že to může mít smysl a nemusí vždy jít o nefunkční klikátko pro lamy.

Přehlednost a jednoduchost

Jistě, ovládání pacmanu je jednoduché, ale pořád se mi zdá, že dělá příliš mnoho věcí naráz. Chápu, že na to máte jiný názor, ale pořád jsem přesvědčen, že by se mělo důsledně oddělit jádro se základní logikou od síťové komunikace, práce se soubory, ukládání metadat a frontendu. Protože jsem tento návrh neomezoval jen na ArchLinux, samozřejmě jsem počítal i se zakomponováním ABS do základní příkazové sady.

Kdo by měl tohle všechno udělat?

Pevně věřím, že se mi podaří najít čas na nějaké úpravy. Přesto si ale myslím, že nemá smysl se vrtat v kódu, s jehož návrhem od základu příliš nesouhlasím. Proto jsem spíš chtěl vyvolat debatu o návrhu možného univerzálního balíčkového systému, který by se podobal pacmanovi ve všem kromě návrhu.

Pokud jde o posílání patchů vývojářům, kdysi dávno jsem poupravil spouštěcí skripty tak, aby přímo podporovaly WPA. Tenkrát šlo WPA v ArchLinuxu zprovoznit jen při současném použití síťových profilů, což mi nepřipadá rozumné, zejména vezmete-li v úvahu, koli věcí zvládá wpa_supplicant zcela automaticky. Proto jsem doplnil skript network tak, aby k podopoře WPA nebyly nutné síťové profily. Poslal jsem svůj návrh do některé z těch diskusí - už si nepamatuju, kam vlastně. Nesetkal jsem se s žádnou odezvou, takže jsem tu věc nechal plavat, zejména kvůli nedostatku času. Je taky dost dobře možné, že tohle už dávno bylo vyřešeno jinak.

[vogo]

Nemám rád slovní spojení "univerzální balíčkovací systém", ale chápu, že zde se nejedná o balíčkovací systém, který by koexistoval vedle jiného v tomtéž distru ;).

O zdrojovém kó

oddělení jednotlivých funkcí, a rozdrobení je právě to co se mi nezamlouvá, například se mi nelíbí jak to funguje u debianu, ale netvrdím že je to spatné, každé řešení má své výhody

absence frontendu mi taky nevadí, ale třeba existuje celkem povedený gtk frontend, ale už je to delší doba co jsem ho zkoušel

takže vidím, že na některých věcech se shodneme :), klidně bych se na takové věci podílel, na něčem jako alternativní správce balíčků pro archlinux, který by používal stejnou databázi jako pacman, prostě něco za pacmana, ale stejně jednoduché, a klidně pluginovatelné, od rána jsem nad tím přemýšlel, a možná by to mělo do sebe ;) třeba plugin, který by tvořil balíčky z ABS, nebo by je rovnou hledal na AURu :) jojo, škoda, že teď nevím kam dřív skočit...

[hikite]

Kdyby to bylo dle mých představ, jede to v sqlite (přímo a bez možnosti jiných - to by zbytečně komplikovalo) a napsané to je v Pythonu. Ale spokojím se i s tím, když to bude v céčku a sqlite .

Párkrát se to tam (v diskuzi na arch) řešilo, stanovisko bylo, že databáze by byla příliš složitá, zaváděla by závislosti a (prý) by to bylo pomalejší . Což je blbost (obzvláště u sqlite), na kterou si vzpomenu, kdykoliv čekám až pacman "dochroustá" a začne něco dělat. Vůči tomuhle zpomalení tam doporučovali jakousi jednoduchou "defragmentaci" (snad něco smazat nebo kýho hroma co), ale já jsem tím dost otráven na to, abych to řešil.

Ty problémy s kódem, frontendy by snad měl pořešit 3.0 a libpacman. Arch je zamýšlen primárně jako binární, zkoušeli jste yaourt s možností "--aur"?

[vogo]

na zvýšení výkonu existuje jeden hack :) už ho dost dlouho používám, a je to jak přesednout ze stodváci do ferrari

[hikite]

Díky za tip, možná při volné nudné chvilce seberu náladu ozkoušet - ale ten problém (spousta malinkých soubůrků dat) ještě elegantněji vyřeší sqlite - a než závislost na reiserFS, to radši na opravdové databázi .

[Andrej]

Já mám ReiserFS na rychlém stroji a ext3 na pomalém. Nerad to říkám, ale na tom ext3 to funguje stejně rychle... Takže je otázka, jestli zrovna pro tenhle druh nasazení je ReiserFS opravdu tak ideální.

Ale je to samozřejmě individuální. Každý má jiný hardware a podobně. Nebo že by tomu ReiserFS nesvědčil anticipatory scheduler? No to je možné, ale CFQ scheduler zase nesvědčí mým empétrojkám, a to ani trochu, takže teď aby si člověk vybral, že ano...

[hikite]

Cha, tak už se na to těším, místo Reiser (mám k němu tak nějak... odpor) totíž zkusím - pro mě dosud neznámý - Spad. Tak ještě jednou dík.

[Andrej]

Přesně tohoto hacku docílí Linux de facto automaticky - přibližně při třetím dotazu je už pak další odezva poměrně slušná, neboť je všechno v diskové cache. To s tím loopbackem je samozřejmě skvělý nápad, ale je to spíš workaround než nějaké trvale únosné řešení.

Já to dělám tak, že spustím pacman -Qe a jdu si nalít limonádu. Když se vrátím, je už celá „databáze“ nachroustaná v diskové cache a další dotazy už mi pak jdou pěkně. (To ovšem platí bohužel jen pro dotazy, nikoliv pro zápis metadat při aktualizaci balíčků. Tam už je to zas tradičně bídné.)

[Andrej]

Vůči tomuhle zpomalení tam doporučovali jakousi jednoduchou "defragmentaci" (snad něco smazat nebo kýho hroma co), ale já jsem tím dost otráven na to, abych to řešil.

pacman-optimize

Ale že by to nějak fungovalo, to se říct nedá. Zrychlilo mi to pacmana možná o třetinu a jen do doby, než jsem zase udělal pořádný update systému. Nejspíš to tu databázi jen zkomprimuje, smaže a znova zapíše, aby se případné fragmentované malé soubory zapsaly spojitě. Nebo to špatně chápu, to je taky možnost...