Kdy mě Gentoo štve

4.12.2005 17:12 | Přečteno: 1722× | Linux | poslední úprava: 4.12.2005 17:13

Portage je skvělá věc. Má spoustu plusů, o kterých víme. Já se v tomto zápisu budu zabývat mínusy.

Portage je pomalý. Byl navržen určitým způsobem, který před léty vyhovoval. S tím, jak se zvýšil počet ebuildů, se nutně musí změnit jeho architektura. Ano, bolelo by to. Ale není vhodné to odkládat. Po seznámení s vývojem tohoto nástroje jsem se však bohužel ujistil v tom, že současný návrh (ala rsync) potrvá nadále. Minimálně několik dalších let.

Řešení vidím dvě. První nešťastná věc je podle mého názoru kombinace velkého množství shell skriptů a adresářů. Díky tomu, že se používá rsync pro synchronizaci jsou ty adresáře nutné. Co třeba tento návrh: uživatel by měl pouze databázi "balíčků" a závislostí (jako u RPM) a ebuild včetně dodatečných souborů a samozřejmě zdrojových kódů by se stahovaly, až když by byl proveden příkaz emerge? Šetřilo by se tím pásmo, čas i diskový prostor. (*)

Jako druhý (realičtější) plán je postupné zušlechťování stromu portage (odstraňování přebytečných věcí), optimalizace programu (v tuto chvíli hodně bolí pomalé závislosti) a podpůrných skriptů. Stávající alternativní backendy ale stejně portage nezrychlí (nástroj musí prostě chodit do spousty adresářů). Nainstalováním souborového systému reiser4 věc nechci řešit.

Pomalost vývoje. O portage se stará asi tři stovky vývojářů (resp. k CVS stromu mají oni přístup). I já příspívám pomocí Bugzilly, jenže ta je opravdu zahlcena záznamy a vývojáři reagují dost pomalu. Velmi bych uvítal nějaký oficiální devel strom (něco jako gentooexperimental.org), který by však byl funkční a podporován komunitou Gentoo. Uživatelé by si mohli ke stávajícímu stromu přidat tento, ve kterém by všechny balíky byly automaticky maskovány, eventuelně by zde byla možnost volit mezi dvěma verzemi (v oficiální a v "unstable"). Tato větev by byla veřejná (něco na způsob WIKI).

Možná by pomohlo také vylepšit feedback od uživatelů. Napadají mě nějaké automatizované volby, zda unmaskovat ebuild. Často se stane, že developer z Bugzilly přesune (upraví) nový ebuild, pochopitelně jej zamaskuje (resp. dá mu arch flag) a bug uzavře. Pro něj je to hotové, ale často se stane, že tento ebuild je pak měsíce a měsíce stále nestabilní.

Konkrétní problémy. Během používání Gentoo sice oceníte výhody, které s sebou přináší portage. Časem ale narazíte na různé konkrétní překážky. Třeba nekonečné (stále nevyřešené) problémy s wxGTK (jedna aplikace potřebuje zakompilovánu podporu pro Unicode, jiná zase s Unicode nefunguje - a teď se rozhodni). Tady ovšem musím poznamenat, že těmito "lokálními" problémy trpí i jiné balíčkovací systémy (jen se odpovědnost přenáší více na vývojáře/package maintainera).

Smyslem zápisu je rozproudit diskusi na toto téma. Gentoo tu byl, je a bude. Je to vyjímečná distribuce.

(*) - možná by stálo za to tuto myšlenku rozvinout. Opravdu nevidím důvod, prož ebuildy a podpůrné soubory (Changelogy, digesty, patche...) udržovat na lokálním disku. Názory?

Další zápisy...        

Komentáře

[David Watzke]

Nová sys-apps/portage-2.0.53 je IMO o něco rychlejší.

[Lukáš Zapletal]

Vím o tom, mám takový merge této verze. Koukal jsem i do toho celkového rewritu, ale týká se to jen vnitřností, nic nového pod sluncem (žádné zásadní změny).

[Jan Kundrát (jkt)]

Řešení vidím dvě. První nešťastná věc je podle mého názoru kombinace velkého množství shell skriptů a adresářů. Díky tomu, že se používá rsync pro synchronizaci jsou ty adresáře nutné. Co třeba tento návrh: uživatel by měl pouze databázi "balíčků" a závislostí (jako u RPM) a ebuild včetně dodatečných souborů a samozřejmě zdrojových kódů by se stahovaly, až když by byl proveden příkaz emerge? Šetřilo by se tím pásmo, čas i diskový prostor. (*)

Zrejme myslis zachovat de facto jenom IUSE, *DEPEND, PV a spol. Hm, tohle ti tak maximalne zrychli synchronizaci z Internetu, ktera ale neni pomala (na `emerge --sync` je pomaly regenerovani cache, zejmena kdyz to narazi na meta ebuildy). Portage samozrejme nepracuje primo s ebuildama, ma z nich nacachovany dulezity informace, obsah samotnych funkci (src_unpack(),...) se zrpacovava jenom tehdy, kdyz je to potreba.

Jako druhý (realičtější) plán je postupné zušlechťování stromu portage (odstraňování přebytečných věcí),

Odebirani balicku? To prece neni reseni.

optimalizace programu (v tuto chvíli hodně bolí pomalé závislosti)

Co to jsou "pomale zavislosti"?

a podpůrných skriptů.

Co to?

Stávající alternativní backendy ale stejně portage nezrychlí (nástroj musí prostě chodit do spousty adresářů).

Nemusi. Jednu dobu IIRC fungoval i SQL-based backend.

Pomalost vývoje. O portage se stará asi tři stovky vývojářů (resp. k CVS stromu mají oni přístup).

To neni pravda. Jsou tu (radove stovky) vyvojaru, co maji prava pracovat s ebuildama, tj. s "balicky". Tohle neni Portage, tohle je "strom Portage". Samotny Portage vyviji radove jednotky lidi, IIRC.

I já příspívám pomocí Bugzilly, jenže ta je opravdu zahlcena záznamy a vývojáři reagují dost pomalu. Velmi bych uvítal nějaký oficiální devel strom (něco jako gentooexperimental.org), který by však byl funkční a podporován komunitou Gentoo. Uživatelé by si mohli ke stávajícímu stromu přidat tento, ve kterém by všechny balíky byly automaticky maskovány, eventuelně by zde byla možnost volit mezi dvěma verzemi (v oficiální a v "unstable"). Tato větev by byla veřejná (něco na způsob WIKI).

Rikas podporovany komunitou. Zadny vyvojar ti nebude podporovat neco, na co nema vliv. Takovy projekty samozrejme existuje, balicek "gensync", kterej s nima usnadnuje praci, je soucasti oficialniho stromu (aspon teda IIRC), tak v cem je problem? BreakMyGentoo, EbuildExchange, GentooExperimental,...

Možná by pomohlo také vylepšit feedback od uživatelů. Napadají mě nějaké automatizované volby, zda unmaskovat ebuild.

/me runs

Často se stane, že developer z Bugzilly přesune (upraví) nový ebuild, pochopitelně jej zamaskuje (resp. dá mu arch flag) a bug uzavře. Pro něj je to hotové, ale často se stane, že tento ebuild je pak měsíce a měsíce stále nestabilní.

1. zrejme myslis ~arch
2. To, aby neco nebylo zbytecne dlouho zamaskovane, se samozrejme hlida. Jsou na to skripty a doba, co se povazuje za "dlouho", je tusim defaultne 30 dni.
3. Pokud te trapi, ze je nejaky ebuild ~arch a ne stabilni, muzes (pokud je v ~arch odmaskovany aspon 30 dni) skuzit poslat request do bugzilly.

Konkrétní problémy. Během používání Gentoo sice oceníte výhody, které s sebou přináší portage. Časem ale narazíte na různé konkrétní překážky. Třeba nekonečné (stále nevyřešené) problémy s wxGTK (jedna aplikace potřebuje zakompilovánu podporu pro Unicode, jiná zase s Unicode nefunguje - a teď se rozhodni). Tady ovšem musím poznamenat, že těmito "lokálními" problémy trpí i jiné balíčkovací systémy (jen se odpovědnost přenáší více na vývojáře/package maintainera).

IMHO jsou tohle problemy balicku a ne distribuce.

Smyslem zápisu je rozproudit diskusi na toto téma. Gentoo tu byl, je a bude. Je to vyjímečná distribuce.

Nejsem si jisty, jestli jsi zvolil spravny server, spravne misto na tomto serveru a zejmena jazyk. Pokud vim, cesky rozumi celkem tri vyvojari Gentoo, s ebuildy z nich pracuje jenom jeden.

(*) - možná by stálo za to tuto myšlenku rozvinout. Opravdu nevidím důvod, prož ebuildy a podpůrné soubory (Changelogy, digesty, patche...) udržovat na lokálním disku. Názory?

• digesty - protoze bezpecnost
• ChnageLogy - protoze rychlost
• patche - pokud vim, jsou pomerne male...

[Spike]

Hmm, kteří to jsou? Možná Spock by s trochou námahy ještě rozuměl. :)

Jinak mám pocit, že se uvažuje o stahování nějaké hotové cache, aby se nemusela vytvářet na cílovém stroji. Jak to ve výsledku vyřeší, to nevím.

Patche jsou sice malé, ale je jich strašně moc a jsou nekomprimované. Vývojáři navíc často files/ zbytečně zneužívají.

[Jan Kundrát (jkt)]

Hmm, kteří to jsou? Možná Spock by s trochou námahy ještě rozuměl. :)

Viz napriklad seznam vyvojaru. A FYI, tech Polaku je tam mnohem vic.

Cesky/SLovensky:

• Ticho - Andrej Kacian (net-mail)
• jakub - Jakub Moc (Main Bug Wrangler)
• jkt - Jan Kundrát (GDP, Czech Translation)

[Lukáš Zapletal]

No nevim nevim, server se tedy nadře -- vytvářet cache každý commit do CVSka...

[Jan Kundrát (jkt)]

FYI, zmeny se nejprve ulozi na CVS server, odkud se "jednou za cas" presunou (po nejakejch upravach) na tzv. master rsync server, rsync1.us.gentoo.org (pro uzivatele nepristupnej), ze ktereho se opet "jednou za cas" synchronizuji na rsync servery (mirrory) po celem svete.

[Lukáš Zapletal]

Ačkoli mají kořenový rsync servery hodně nadupaný, vytvoření cache trvá dost času i na _velmi_ rychlým stroji. Zapotí se tak jako tak, nehledě na to, jak často se to přesouvá...

[Lukáš Zapletal]

Portage samozrejme nepracuje primo s ebuildama, ma z nich nacachovany dulezity informace, obsah samotnych funkci (src_unpack(),...) se zrpacovava jenom tehdy, kdyz je to potreba.

To ano, problém je v samotné cache. Já osobně odmítám nazývat adresář /var/db/pkg jako cache. Nepodléhá to samotné definici tohoto slova: rychlá pamět (A memory area where frequently accessed data can be stored for rapid access. -- Google). Nepomáhájí ani žádná ad-hoc řešení. Je to stále pomalé a musí se to předělat. (Doporučuji dát strace emerge -up world).

Odebirani balicku? To prece neni reseni.

Ne ale v tuto chvíli jediná možnosti jak to řešit.

Co to jsou "pomale zavislosti"?

To co zmiňuji nahoře. Někdy se nevyjadřuji úplně jasně -- podpůrné skripty = soubory z files/ (jsou tam různé build skripty atd).

Jednu dobu IIRC fungoval i SQL-based backend.

To je právě ono. Ono to možná fungovalo, ono to někomu fungovalo, ale v mainstreamu se zatím jen uklízí špatně naprogramovaný portage. Já sám jsem chtěl přiložit ruku k dílu, ale když jsem vyděl tu hrůzu, tak jsem od toho dal ruce pěkně rychle pryč.

Ad portage vs "strom portage" -- pochopils správně, zapomněl jsem na slovo "strom"

BreakMyGentoo, EbuildExchange, GentooExperimental

První dva jmenované servery vypadají dobře! O prvním jsem si myslel, že se jedná o nějakou security záležitost a až po Tvém příspěvku jsem si přečetl, že tomu tak není. Druhý jsem navštívil ještě v příliš ranné verzi. Vypadá to, že to je již použitelné. Třetí nefunguje (zrovna dneska)...

/me runs

Teď zase nachápu já

To, aby neco nebylo zbytecne dlouho zamaskovane, se samozrejme hlida. Jsou na to skripty a doba, co se povazuje za "dlouho", je tusim defaultne 30 dni.

To jsem nevěděl o těch skriptech... Každopádně nějakých 300 vývojářů (psal mi to myslím Jakub, nevím, jestli je to pravda) je IMHO dost málo na to, kolik má portage tree ebuildů. No, mají se co ohánět.

Prima, já jdu zkoumat ty dva servery a nahraju tam asi nějaký ten ebuild

[paskma]

A vážně nepomůže mít na portage samostatný Reiser4 oddíl? Respektive pokud to pomůže, není to snad taková bolest. A mít na R4 systém (tedy ne home) snad není až takové riziko.

[Lukáš Zapletal]

Ono to pomůže, ale já si myslím, že by se mělo programovat tak, aby nebyl uživatel nucen do takovýchto ad-hoc akcí. A navíc -- ne každý má speciální oddíl na /usr/portage.

[paskma]

Mělo, mělo. Mělo by se programovat hlavně korektně - aby to fungovalo. Optimalizace jsou drahé

No a pokud je to ad-hoc filesystémová databáze s hromadou pidi souborů tak použití ad-hoc FS, který (pokud to řeší) je korektní. Navíc R4 je univerzální FS.

Samozřejmě uznávám, že přidání oddílu do existující instalace je problém. Bylo by hezké, kdyby to bylo napsane efektivněji, ale ono to vzniklo nějakou evolucí. Není možné každý program psát předimenzovaně.

[xkesh]

přidání oddílu do existující instalace je problém.

Kdyz je na ten oddil jeste misto, tak to neni prakticky zadny problem. Vytvorit oddil (fdisk, cfdisk), vytvorit file system, namountovat, prekopirovat patricny adresar, pripsat do /etc/fstab, a je to.

Kdyz misto neni, daji se dosavadni oddily (s urcitym rizikem, pravda) zmensovat.

[paskma]

Volné místo na disku nenecháváma ani nikoho takového neznám. Místa je vždy málo.

[VícNežNic]

Mám teď bokem deset giga, které nepotřebuju, tak jsou jako volné místo…

[Lukáš Zapletal]

Navíc neznám nástroj, který by to v Linuxu zvládnul. Všechny mé pokusy o zmenšování oddílů dopadly fiaskem a řešil jsem to tedy nakopírováním dat na externí disk. A kupovat nějaký nástroj na jednorázovou akci si určitě nebudu.

[Semo]

Vytvorit velky subor a R4 vytvorit na nom sa da aj na uplne alokovanom disku.

[paskma]

Jo. A pak to jede přes 2 filesystémy. No, možná pokud by ten soubor nebyl fragmentovaný tak by to i nějaké zrychlení přinést mohlo.

[Lukáš Zapletal]

Jenže vy jste asi neviděl zdrojový kód portage (stabilní větev). To není tak, že to není optimalizované. To je prasácky napsané, je to katastrofální hrůza, ukázka, jak se nemá programovat v Pythonu. Není to optimalizované proto, že to ani udělat ve stávající verzi nelze (muselo by se zasahovat na mnoha místech atd atp).

Právě proto se portage přepisuje, jenže těch změn bude tolik, že si troufám tvrdit, že verzi 3.0 spatříme nejdřív za rok. Ale máme se na co těšit, vychytávky jako vzdálený portage tree (a s ním spojená administrace skupin počítačů na dálku), vysoký výkon, možnost vyměny storage (flat soubory, SQL...) a runtime pluginy.

Portage byl (už jsem to někde psal) zkrátka dimenzován na nějakých 500 balíčků, už dávno to mělo být přepsané.