Proč jsem přešel z Gentoo na Arch

11.6.2005 04:27 | Přečteno: 2688× | Linux | poslední úprava: 22.11.2005 19:17

Už jsem na pár místech sliboval, že vysvětlím důvody, které mě vedly k přechodu z mého milovaného Gentoo na můj (nyní již také milovaný) Arch Linux... takže tady to máte

Začátky (klidně přeskočte )

Asi tak před 2 lety (možná o něco málo déle) jsem přešel z Windows na Linux. Mojí první distribucí byl Red Hat 8.0 (který jsem velmi brzy upgradoval na 9.0). Vše bylo krásné a začal jsem pomalu pronikat do světa Linuxu. Ovšem asi tak po roce, když jsem již do tajů Linuxu jakž takž pronikl, mi Red Hat přestal vyhovovat. Za tu dobu se z mé instalace Red Hatu stala nesmírně "bloated" věc (nebo možno také použít výrazu "bordel" ), zažil jsem si trochu toho RPM dependency hell a hlavně mi strašně vadilo, že jsem v Red Hatu neměl dokonalou kontrolu nad systémem. Systém jakým v Red Hatu byly řešeny některé konfigurace, atp. se mi prostě zhnusil.

Vzhledem k tomu, že jsem chtěl mít nad systémem opravdu dokonalou kontrolu (a už tehdy se mi líbila myšlenka kompilace celé distribuce ze zdrojáků), rozhodoval jsem se mezi dvěmi možnostmi - Linux From Scratch a Gentoo. Jelikož nejsem masochista (nic proti lidem kteří LFS používají, obdivuji je ) a svůj system sem chtěl mít neustále aktuální, rozhodl jsem se nakonec pro Gentoo.

Mé milované Gentoo

Gentoo jsem si nesmírně zamiloval. Nejvíce mě na něm uchvátila portage, rychlost a stálá aktuálnost systému. Vskutku ze začátku jsem měl vždy prakticky ihned ty nejnovější verze programů a to jsem používal stable x86 system. Princip "rolling-updates" jsem si zamiloval, někdo může sice potřebou mít vždy ty nejaktuálnější verze programů opovrhovat, ale každý jsme prostě jiný a máme jiné priority

Za tu dobu co jsem používal Gentoo jsem se (nejen) o Linuxu naučil neuvěřitelnou spoustu věcí. Stále se považuji za začátečníka (protože člověk se má pořád co učit), ale to nic nemění na tom, že Gentoo mě k získávání stále nových a nových informací a zkoušení nových věcí nesmírně motivovalo. Je pravda, že instalaci Gentoo podle dokumentace by zvládl možná každý kdo umí číst a dělal někdy na PC, ale Gentoo prostě člověka tak nějak vede k tomu, aby se toho o Linuxu naučil více.

Co mě tedy k přechodu z Gentoo na Arch Linux dovedlo? Vždycky sem chtěl mít system co nejaktuálnější, ovšem nechtěl jsem nad ním ztrácet kontrolu. Zprvu jsem i při použití stable x86 system krásně aktuální měl, avšak později jsem musel přidávat stále více a více věcí do /etc/portage/package.keywords jako unstable ~x86. Nakonec to dopadlo tak, že můj soubor package.keywords měl délku přes 6 obrazovek a pomalu mi začínala docházet trpělivost. Zvažoval jsem i kompletní přechod na ~x86, ale to se z mého hlediska rovnalo ztrátě kontroly nad systemem, čemuž jsem se chtěl za každou cenu vyvarovat. Některé ebuildy byly navíc neaktuální i v jejich ~x86 verzi, jiné zas byly hard-masked (a odmaskovávat hard-masked ebuildy jsem opravdu nechtěl). A co mě ještě více vadilo - spousta balíčků v portage vubec nebyla a musela se hledat po fórech a v bugzille.

To všechno by ani nebyl až zas takový problém, ovšem poslední kapkou bylo, když jsem viděl jak se spousta ebuildů na novější verze či chybějící programy sice válí v bugzille, nicméně se tam válela již dosti dlouho a to že by byly přijaty do portage se jevilo v nedohlednu. Gentoo developeři (kterých si jinak velmi vážím, prosím neberte to nijak špatně!) se sice omlouvali stylem "je nás málo", ovšem že by začali více přijímat nové developery z řad komunity nebo zrevidovali system přijímání ebuildů a udělali ho otevřenější komunitě, to ne.

Můj milovaný Arch

A tak jsem tedy vyzkoušel Arch. A jsem s ním spokojen Na Archu se mi líbí, že je to nesmírně čistý system (podobně jako Gentoo nebo Slackware... osobně jej právě považuji za spojení toho nejlepšího z Gentoo a Slackwaru), disponuje výborným balíčkovacím managerem pacman (který se v mnohém vyrovná emerge a v něčem ho i předčí - třeba v tom že podporuje "reverse dependencies") a ABS (Arch Build Systemem), což je systém portů podobných portage pro kompilaci ze zdrojáků. Navíc je Arch optimalizován pro i686 a jedná se o vskutku velmi rychlý system. Co je ovšem pro mě taktéž velmi důležité - striktně se drží filosofie "rolling-updates" a vždy máte k dispozici ty nejnovější verze programů, některé často novější i než unstable ~x86 verze v Gentoo.

Co se mi také hrozně moc líbí na Archu je jeho otevřený přístup ke komunitě. Na stránkách archu máte AUR (Arch User Repository) - repozitář PKGBUILDů (obdoba ebuildů z Gentoo určená pro Arch Build System), kam může naprosto každý přispívat svými vlastními PKGBUILDy. Neznamená to ovšem, že by zde neexistovalo žádné QA - nad AUR dohlíží skupina Trusted Users, kteří ho mají rozděleni podle kategorií a oblíbené PKGBUILDy mohou přijmout pod svůj patronát (přejdou z unsupported do community), načež později mohou přejít i do oficiálního extra či current repozitáře Archu. Tohle je přesně ten otevřený přístup ke komunitě, který mi u Gentoo chyběl, což mě ve svých důsledcích dovedlo až k tomu, že jsem přestoupil na Arch.

I přes to všechno co jsem napsal se prosím nenechte zmýlit - Gentoo stále považuji za z mého pohledu nejlepší distribuci pod Sluncem a pokud se v něm situace zlepší, možná se k němu v budoucnosti vrátím...

       

Komentáře

[Martin Beránek]

ano cesta ke gentoo byla u mne obdobna... a trapi me stejne veci...

umi tedy arch kompilovat programy tak jak to umi gentoo - tedy puze s vybranymi zavislostmi a jak je to tam reseno?

ps: zatim toho v ~x86 moc nemam (cele kde a par drobnosti). hard masket take pouzivam (treba momentalne amarok) ale je pravda ze obcas spadne.

[JaMa]

Pouzivam jeden system s x86 a par baliky (<10) z ~x86 a jsem spokojen

Druhy system mam na ~x86 se spoustou odmaskovanych baliku, nekolika baliky z fluidportage (cvs verze) a system je z 50% prekompilovany gcc-4.1 a stejne nepozoruju nejake padani.

Myslim ze zase tak spatne to neni..

[Martin Beránek]

mit tolik mista na disku na dva systemy... ale mam jen 40G hadr a to tak staci na ty WinXP na hry, Linux na praci a data...

[Mikos]

"umi tedy arch kompilovat programy tak jak to umi gentoo - tedy puze s vybranymi zavislostmi a jak je to tam reseno?"

Arch je stavěn jako binární distribuce, Arch Build System je pouze doplňková věc, aby sis mohl libovolný program jednoduše překompilovat (a vytvořit z něj balíček) se svými možnostmi (pokud se ti u nějakého programu nelíbí jeho defaultní nastavení). Nebo aby sis mohl lehce vytvořit PKGBUILDy pro nové programy. Nicméně nic jako USE flagy nepodporuje, bylo by to v takovémto případě (jak se Arch jako distribuce profiluje) myslim i docela zbytečné...

[Mikos]

Ovšem závislosti (jak runtime závislosti, tak případné závislosti nutné pouze ke kompilaci) v PKGBUILDu samozřejmě nastavuješ...

[Jan Kundrát (jkt)]

Nicméně nic jako USE flagy nepodporuje, bylo by to v takovémto případě (jak se Arch jako distribuce profiluje) myslim i docela zbytečné...

Navic IMHO i neresitelne, proste by nemeli sanci udelat buildy tolika balicku...

[JaMa]

Kdyz nejaky neni v portage tak pouzivam postup Bugzilla, Forum, Google a resi to 70% pripadu. Ve zbyvajicich 30% se vyplati poslat request do bugzilly a pokud clovek chce prispet komunite tak do Bugzilly poslat i vlastni ebuild. On ho obcas nekdo zkusenejsi jeste parkrat zreviduje a pokud bude uzitecny a ok tak se urcite casem dostane i do portage.

[Jan Kundrát (jkt)]

Zvažoval jsem i kompletní přechod na ~x86, ale to se z mého hlediska rovnalo ztrátě kontroly nad systemem, čemuž jsem se chtěl za každou cenu vyvarovat.

Jak to myslis? Jaka ztrata kontroly?

Některé ebuildy byly navíc neaktuální i v jejich ~x86 verzi, jiné zas byly hard-masked (a odmaskovávat hard-masked ebuildy jsem opravdu nechtěl).

Z jakeho duvodu? Pokud si myslis, ze vis lepe nez vyvojari distribuce, ze dany balicek bude stabilni, tak si ho klidne odmaskuj. Ale pokud jim veris, ze to opravdu blbne, tak nechapu, kde beres jistotu, ze to jinde blbnout nebude.

A co mě ještě více vadilo - spousta balíčků v portage vubec nebyla a musela se hledat po fórech a v bugzille.

http://www.gentoo.org/proj/en/devrel/staffing-needs/index.xml

To všechno by ani nebyl až zas takový problém, ovšem poslední kapkou bylo, když jsem viděl jak se spousta ebuildů na novější verze či chybějící programy sice válí v bugzille, nicméně se tam válela již dosti dlouho a to že by byly přijaty do portage se jevilo v nedohlednu. Gentoo developeři (kterých si jinak velmi vážím, prosím neberte to nijak špatně!) se sice omlouvali stylem "je nás málo", ovšem že by začali více přijímat nové developery z řad komunity nebo zrevidovali system přijímání ebuildů a udělali ho otevřenější komunitě, to ne.

A co maji delat? Davat commit access do portage kazdemu, kdo submittne dva ebuildy? Co treba nejaky "rm in global scope", cili jeden malicky ebuild, ktery ti pri `emerge sync` "smaze pulku systemu" (on je tam sandbox, ale jde o princip - proste tyhle prava se nerozdavaji automaticky...)?

[Mikos]

"Jak to myslis? Jaka ztrata kontroly?"

V okamžiku kdy přejdu na celý systém unstable ~x86 kontrolu (alespoň z mého pohledu) opravdu částečně ztrácím. Věci se pak velmi rychle mění a za tu dobu co používám Gentoo se v ~x86 už párkrát nějaké kritičtější problémy objevili. Pokud vím přesně které balíčky mám unstable, prostě mám nad tím větší kontrolu. Navíc v případě použití unstable ~x86 bych částečně ztratil podporu developerů v případě nějakých problémů (respektive řešení problému by mohlo trvat o dost déle). Prostě preferuju takovou distribuci, která bude plně aktuální (a spodporou) i v její stable verzi. Jsou to mé preference, nic jiného...

"Z jakeho duvodu? Pokud si myslis, ze vis lepe nez vyvojari distribuce, ze dany balicek bude stabilni, tak si ho klidne odmaskuj. Ale pokud jim veris, ze to opravdu blbne, tak nechapu, kde beres jistotu, ze to jinde blbnout nebude."

Šlo o věci jako třeba Java 1.5 (od Sunu). Důvod proč byla (a možná ještě je) hard-masked sem si samozřejmě četl, ale zajímavé je, že v jiných distribucích (tedy tam kde Java vubec je ) to nedělá problémy ) Ale byly i jiné příklady (na které si teď už asi nevzpomenu), u kterých mi důvod jejich hard-maskování přišel (z mého hlediska) neoprávněný.

"A co maji delat? Davat commit access do portage kazdemu, kdo submittne dva ebuildy? Co treba nejaky "rm in global scope", cili jeden malicky ebuild, ktery ti pri `emerge sync` "smaze pulku systemu" (on je tam sandbox, ale jde o princip - proste tyhle prava se nerozdavaji automaticky...)?"

To je jednoduché (a v mém příspěvku jsem to také napsal) - buď udělat aktivnější proces přijímání nových developerů z řad uživatelů (což ovšem není nutné a mohlo by to být i kontraproduktivní), nebo založit něco na způsob Arch User Repository, který funguje velmi dobře. Jak jsem psal QA by v takovém případě nechybělo - byly by tam prostě 2 kategorie ebuildů - "unsupported" (za které by nikdo neručil, mohli by být vyprodukovány kýmkoliv) a ty by lidé ze skupiny Trusted Users mohli přijmout vždy pod svůj patronát, načež by se staly "supported" a následně se přesunuly do portage. Takovýto centralizovaný systém (který by si lidé mohli přímo přidat jako zdroj do portage) by byl rozhodně lepší než to když se hromada ebuildů povaluje po fórech a v bugzille. Bylo by to otevřenější komunitě a mohlo to urychlit cestu nových ebuildů do portage.

[Jan Kundrát (jkt)]

"Jak to myslis? Jaka ztrata kontroly?"

V okamžiku kdy přejdu na celý systém unstable ~x86 kontrolu (alespoň z mého pohledu) opravdu částečně ztrácím. Věci se pak velmi rychle mění a za tu dobu co používám Gentoo se v ~x86 už párkrát nějaké kritičtější problémy objevili. Pokud vím přesně které balíčky mám unstable, prostě mám nad tím větší kontrolu.

Nejak se mi nechce verit, ze by Arch Linux (ktery podle meho odhadu bude mit asi mensi user-base i pocet vyvojaru nez Gentoo, ktere tu uz nejaky ten patek je) mel lepsi QA nez Gentoo, i kdyz muze byt.

Navíc v případě použití unstable ~x86 bych částečně ztratil podporu developerů v případě nějakých problémů (respektive řešení problému by mohlo trvat o dost déle).

To neni pravda. Proc by to melo trvat dele? Samozrejme musis hlasit bugreporty v rozumen podobe, ne "GNOME stopped working".

Prostě preferuju takovou distribuci, která bude plně aktuální (a spodporou) i v její stable verzi. Jsou to mé preference, nic jiného...

Jak muze neco byt "stabilni, vyzkouseny a podporovany", kdyz je to tri hodiny stare?

"A co maji delat? Davat commit access do portage kazdemu, kdo submittne dva ebuildy? Co treba nejaky "rm in global scope", cili jeden malicky ebuild, ktery ti pri `emerge sync` "smaze pulku systemu" (on je tam sandbox, ale jde o princip - proste tyhle prava se nerozdavaji automaticky...)?"

To je jednoduché (a v mém příspěvku jsem to také napsal) - buď udělat aktivnější proces přijímání nových developerů z řad uživatelů (což ovšem není nutné a mohlo by to být i kontraproduktivní), nebo založit něco na způsob Arch User Repository, který funguje velmi dobře. Jak jsem psal QA by v takovém případě nechybělo - byly by tam prostě 2 kategorie ebuildů - "unsupported" (za které by nikdo neručil, mohli by být vyprodukovány kýmkoliv) a ty by lidé ze skupiny Trusted Users mohli přijmout vždy pod svůj patronát, načež by se staly "supported" a následně se přesunuly do portage. Takovýto centralizovaný systém (který by si lidé mohli přímo přidat jako zdroj do portage) by byl rozhodně lepší než to když se hromada ebuildů povaluje po fórech a v bugzille. Bylo by to otevřenější komunitě a mohlo to urychlit cestu nových ebuildů do portage.

Takovy "system" tu uz je. Predpokladam, ze i Arch to resi tak, ze aby ses mohl stat "Trusted Userem", musis neco delat, napriklad casto opravovat chyby v baliccich od jinejch lidi. Myslim, ze pokdu budes v Gentoo Bugzille dostatecne aktivni, dostanes commit access taky.

BTW, co ti brani na mailu na gentoo-dev ML a navrhu, ze nejaky podobny "repozitar" udelas?

[jm]

To neni pravda. Proc by to melo trvat dele? Samozrejme musis hlasit bugreporty v rozumen podobe, ne "GNOME stopped working".

No samozrejme, ze to je uplny nesmysl, od toho tam prece ty unstable verze jsou, aby se odladily chyby.

[jm]

< Šlo o věci jako třeba Java 1.5 (od Sunu). Důvod proč byla (a možná ještě je) hard-masked sem si samozřejmě četl, ale zajímavé je, že v jiných distribucích (tedy tam kde Java vubec je ) to nedělá problémy )

To bude asi tim, ze v jinych distribucich uzivatele proti te Jave nekompilujou balicky... :-P Co si treba projit bugzillu a zjistit, kolik veci se s tim neda zkompilovat nebo je jinak rozbitych?

nebo založit něco na způsob Arch User Repository, který funguje velmi dobře.

Uz jsem ti jednou psal, at si do overlay das, co uznas za vhodne. Existuje i nekolik predpripravenych jinymi lidmi, coz ovsem nebrani blbcum psat do Gentoo bugzilly, ze jim ty ebuildy buhviodkud nefungujou.

[Mikos]

"Co si treba projit bugzillu a zjistit, kolik veci se s tim neda zkompilovat nebo je jinak rozbitych?"

Jenze jsou take veci, ktere bez Javy 1.5 nefunguji. A v mnoha ohledech je Java 1.5 podstatne rychlejsi nez predchozi verze. Je to proste otazka priorit, co je dulezitejsi... z meho pohledu by bylo proste lepsi (a logictejsi) aby Java 1.5 byla pouzeble (a ne hard-masked).

"Uz jsem ti jednou psal, at si do overlay das, co uznas za vhodne. Existuje i nekolik predpripravenych jinymi lidmi, coz ovsem nebrani blbcum psat do Gentoo bugzilly, ze jim ty ebuildy buhviodkud nefungujou."

No a to je prave to co mi vadi - je v tom pak hrozna roztristenost a vyhledavat ruzne zdroje je obcas pekne zdrzujici. NAvic ma clovek v pripade veci z takovych zdroju nulovou podporu od Gentoo developeru. Proto rikam ze je mnohem lepsi system centralizovaneho (to slovo "centralizovaneho" je tu kliceve) komunitniho repozitare, kam by mohl ebuildy prispivat zcela kdokoliv a oni "Trusted Users" by nad tim dohlizeli. Zkratka po vzoru modelu Arch User Repository, ktery podle me funguje vyborne.

[Mikos]

Jen jeste dodak k te Jave - to byl pouze priklad, takovych veci je vice...

Zkratka to shrnu tak, ze model jakym funguji repositare v Arch Linuxu (a jeho v tomto ohledu vetsi otevrenost komunite) je mi mnohem sympatictejsi, coz me take dovedlo k tomu, ze jsem z Gentoo na Arch presel. To je vse, o tom byl cely muj prisevek v blogu...

[jm]

NAvic ma clovek v pripade veci z takovych zdroju nulovou podporu od Gentoo developeru. Proto rikam ze je mnohem lepsi system centralizovaneho (to slovo "centralizovaneho" je tu kliceve) komunitniho repozitare, kam by mohl ebuildy prispivat zcela kdokoliv a oni "Trusted Users" by nad tim dohlizeli.

No tak nulovou podporu bys mel tak jako tak, jestli by to bylo uskladneno na jednom miste nebo na deseti. Ebuildy v pouzitelnem stavu se dostanou do portage, se zbytkem si porad, jak chces. Opravdu nemam pocit, ze by tam tech balicku bylo malo.

[jm]

To všechno by ani nebyl až zas takový problém, ovšem poslední kapkou bylo, když jsem viděl jak se spousta ebuildů na novější verze či chybějící programy sice válí v bugzille, nicméně se tam válela již dosti dlouho a to že by byly přijaty do portage se jevilo v nedohlednu.

Tak si udelej vlastni overlay a tam si je pridej a spravuj a uved je do takoveho stavu, aby se do portage dostaly. Naprosta vetsina tech, co v bugzille jsou, v takovem stavu bohuzel neni...

[xkesh]

Vždycky sem chtěl mít system co nejaktuálnější, ovšem nechtěl jsem nad ním ztrácet kontrolu.

Tak jsem prave zjistil, ze na stroji, kam jsem si dal AL, nefunguje nejnovejsi nividia driver, protoze nvidia prestala jiste starsi karty podporovat.

Nevadi, reknu si, udelam downgrade ... a asi hodinu uz hledam, jak je to jednoduse mozne. Asi neni. S touhle moznosti evidentne pacman nepocita, takze pokud si chci nainstalovat starsi verzi nvidia nez tu, ktera je momentalne v current, asi me ceka shaneni po vsech certech nebo si ze starych zdrojaku zkompilovat vlastni balicek.

Dobra. Jen si tak nejak predstavuju "kontrolu nad systemem" ponekud jinak (napr. jako v Gentoo, ze napisu emerge =nividia-kernel-1.0.7104 a on se mi nainstaluje PRESNE tenhle).

Prvni vec, kterou bych AL vytknul. Ze si neco musim zadat rucne do pacman.conf, to mi vubec nevadi. Ale vadi mi, kdyz nemuzu jednoduse udelat to, co udelat chci (napr. nainstalovat jednoduchym povelem zvolenou verzi balicku).

Nebo jsem nekde prehledl snadne reseni?

[Michal Karas]

Zadat prikaz pacman -U /var/cache/pacman/pkg/nvidia-srara_verze.pkg.tar.gz a do /etc/pacman.conf pridat: IgnorePkg = nvidia?

Takhle bych to teda asi resil ja.

[xkesh]

Zadat prikaz pacman -U /var/cache/pacman/pkg/nvidia-srara_verze.pkg.tar.gz

Takhle bych to jiste resil, kdybych na zminenem miste starsi verzi mel, neboli kdyby neslo o prvni instalaci. Kdyz jsem psal, ze hodinu hledam, tak to nebyl jen recnicky obrat.

[Michal Karas]

No tak v tom pripade aktualizovat ABS, upravit PKGBUILD na pozadovanou verzi a pustit makepkg, jak psal Mikos. Rekl bych, ze to je docela jednoduche.

[Mikos]

Bud to muzete resit zcela jednoduse tak, jak vam nize navrhuje Michal Karas, nebo proste a jednoduse pouzijte ABS, v PKGBUILDu pro nvidia drivery zmente cislo verze na starsi, pomoci makepkg ji zkompilujte, pomoci pacman -U nainstalujte a nasledne do pacman.conf pridejte radek IgnorePkg = nvidia. Nevim jak vam, ale me to slozite neprijde. Arch Linux se profiluje jako distribuce pro pokrocile uzivatele a tem by neco takoveho problemy myslim delat nemelo.

"Jen si tak nejak predstavuju "kontrolu nad systemem" ponekud jinak (napr. jako v Gentoo, ze napisu emerge =nividia-kernel-1.0.7104 a on se mi nainstaluje PRESNE tenhle)."

Zapominate na to, ze Arch je narozdil od Gentoo binarni distribuci. Skladovat binarni balicky pro vsechny mozne starsi verze by nebylo zrovna efektivni. Kdyz chcete jinou verzi nez je defaultne v Archu nabizena, tak od toho tu je Arch Build System, abyste si ji zkompiloval.

[jm]

Zapominate na to, ze Arch je narozdil od Gentoo binarni distribuci. Skladovat binarni balicky pro vsechny mozne starsi verze by nebylo zrovna efektivni.

Huh? Eh? Souvislost? Unikla?

Kdyz chcete jinou verzi nez je defaultne v Archu nabizena, tak od toho tu je Arch Build System, abyste si ji zkompiloval.

Huh^2? Vy mate zdrojaky k tem nVidia ovladacum?

[Mikos]

Pokud o tom nevite, tak k casti nvidia ovladacu opravdu zdrojaky mate a kompilujete si je Ovsem jde jen o modul co se vklada do kernelu, ktery sam o sobe nic nedela, jen pouziva ony closed-source binarni ovladace

[Mikos]

"Huh? Eh? Souvislost? Unikla?"

Souvislost je zcela jednoducha - jak by asi bylo mozne v repositari binarni distribuce skladovat balicky pro vsechny mozne starsi verze ruznych programu? To by zabiralo ponekud hodne mista... proto si logicky nemuzete dovolit to co v Gentoo, ze proste emergnete ebuild pro libovoulnou starsi verzi programu. Nicmene ekvivalent tu je - staci pouzit Arch Build System a v PKGBUILDu pro nvidia ovladace proste a jednoduse zmenit cislo verze na starsi a pomoci makepkg si nechat vytvorit balicek, ktery pak pacmanem nainstalujete.

[jm]

Ano, pravda - skladovat balicek se zdrojaky nebo skladovat balicek s binarkami, to je ohromny rozdil!

[Jan Kundrát (jkt)]

No, to je, protoze binarky u Archu vytvari nejakej Arch-Linux team (aspon bych si tipnul), a tudiz je upstream neskladuje, zatimco u Gentoo mas zajem jenom o zdrojaky od upstreamu, ktery pravda Gentoo mirroruje. Jenomze je mirroruje jenom po omezenou dobu (v praxi to funguje asi tak, za kdyz se z Portage stromu odstrani ebuild, skript po nejake dobe smaze i tarball z mirroru). Cili u Gentoo mas sice moznost ziskat vsechny ebuildy az do soucasnosti (z CVS), ale stejne budes nekde potrebovat sehnat stare tarbally, a pokud je upstream po dvou letech smaze, mas smulu.

U Archu je to asi jiny, protoze bude mit nejspis jenom jednu verzi od kazdeho baliku (nebo se pletu? ma jich vic?), zatimco Gentoo jich muze mit (a casto ma) vic, treba deset.

[jm]

Hmm, stale nechapu ten velky rozdil mezi skladovanim zdrojaku a binarek. Ja jsem snad nekde psal, ze by je meli skladovat vsechny? Ono by stacilo vic nez jednu, zejmena u ovladacu...

Pokud je v Archu k dispozici jedna verze ovladacu pro ATI a jedna pro nVidii (nejlepe ta posledni s nejvice problemy), tak by se mel nad sebou nekdo zamyslet...

[xkesh]

nebo proste a jednoduse pouzijte ABS, v PKGBUILDu pro nvidia drivery zmente cislo verze na starsi, pomoci makepkg ji zkompilujte, pomoci pacman -U nainstalujte a nasledne do pacman.conf pridejte radek IgnorePkg = nvidia. Nevim jak vam, ale me to slozite neprijde.

Diky, vskutku to slozite nevypada. Pokus v praxi dneska rano ovsem nedopadl nejlip, tady jsem se o tom rozepsal. Ty uz jsi neco takhle downgradoval?