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

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