Do ledna 2005, byli pouze KDE ebuildy v Portage 'monolitické'. To jest, bylo pouze 15 ebuildů (kdebase, kdenetwork, ...), a každý z nich instalovaný mnoha aplikacemi které, ve skutečnosti, nebyli na sobě závislé. Toto byla zřejmě "optimální" situace, a né velmi přátelská s Gentoo, ale bylo to tolerováno po dlouho dobu.

Nové 'rozdělené' ebuildy (pro konqueror, kmail, ...) upřesnili situaci poskytováním oddělených ebuildů pro všechny oddělené KDE aplikace. To nám dalo veliký úhrn okolo 330 nových ebuildů v kategorii kde-base.

Stále poskytujem monolitické ebuildy pro KDE 3.4 a 3.5 a jsou schopné jasně spolupracovat s rozdělenými. Nicméně, rozdělené ebuildy jsou nový standard, a už nebudou žádné monolitické ebuildy pro KDE 4.0.

Nakonec, by mělo být zmíněno že jsou rovněž rozdělené ebuildy pro Koffice. Tyto poskytují kword, kugar atd. jako oddělené balíčky

Poslední stabilní uvolněné KDE, jako u tohoto psaní, je 3.4.3. Poslední nestabilní (package.masked) je 3.5.0_beta2. Rozdělené a monolitické ebuildy pro obě uvolnění jsou přítomné v Portage.

• K emergování jednotlivých balíčků, jako je kmail, jednoduše emerge kmail.
• K emergování základního prostředí KDE umožňující přihlášení do minimálního "sezení" KDE , emerge kdebase-startkde.
• Nakonec, pro přesný ekvivalent jednoho z monolitických balíčků &ndash pro instance, pro obdržení všech aplikací zahrnutých v kdebase používající rozdělené ebuildy &ndash můžete emerge kdebase-meta (nebo kdepim-meta, atd.) K obdržení absolutně všech rozdělených KDE ebuildů, emerge kde-meta.

Máte-li nainstalován KDE 3.3.x, můžete jednoduše zadat emerge kde-meta k instalaci 3.4.x rozdělených ebuildů bez narušení existující instalace. To samé se dá použít i na 3.5.x

Máte-li nainstalovány KDE 3.4.x monolitické ebuildy, musíte je odebrat (pomocí unmerge) před přidáním rozdělených ebuildů. Nicméně, tento proces může být udělán pro každý monolitický ebuild zvlášť; nemusíte odebírat vše z KDE najednou.

Pochybujete-li, pamatujte si, že existují blokováné části v místech mezi každým monolitickým ebuildem a z toho plynou odvozené rozdělené ebuildy. Portage vám neumožní vytvořit nedovolený stav, takže jakékoliv emerge nebo unmerge, které povolí je v pořádku.

Stručný seznam toho, co získáme přechodem na rozdělené ebuildy:

• Většina KDE balíčků se vůbec nezmění mezi menším uvolněním KDE (minor releases). Například, aktualizace z 3.3.1 na 3.3.2 změní méně než 100 balíčků z 320. Rozdělené balíčky umožňují vytvořit nové ebuildy pouze pro aktuálně změněné balíčky, což ušetří (v tomto případě) víc než dvě třetiny času kompilace při aktualizaci.
• Záplaty (patche) obvykle zasáhnou specifické balíčky. S rozdělenými ebuildy, můžou být rychleji otestovány, schváleny a odevzdány, vývojáři mají měně práce; a jak bylo zmíněno výše, uživatel stráví měně času aktualizací. Toto je zvláště důležité při bezpečnostní aktualizaci.
• Uživatelé jiných desktopů a naklonění WMs mohou přidat (emerge) několik KDE aplikací, které se jim líbí, bez (docela velké) režije zbytku, řekněme, kdebase nebo kdepim.
• Uživatelé mohou doladit balíčky, které si již nainstalovali. Důvody jsou takové:
  • Bojíte se doby překladu? emerge kdebase kdepim kdenetwork vezme strašně dlouhý čas a to co skutečně potřebujete je konqueror, kmail a kopete. Kromě toho, čas CPU jsou peníze... někde :-)
  • Bojíte se zaplnění disku?. Každý nepoužítý balíček je mnoho megabajtů blokující póry mezi Vašimi sektory disku. Prázdnější disk dýchá svobodněji; je rychlý, šťastný to disk :-)
  • Máte strach o bezpečnost systému?. Veškerý instalovaný software je potencionální zdroj zranitelnosti, a není žádné omluvi pro nepoužítý software jen tak ležící na disku.
  • Poctivě se držíte Gentoo směru a nemůžete vystát dohromady svázané balíčky a nutit to uživateli. (My také ne)
• Nakonec, rozdělené ebuildy také umožňují více flexibilní čas kompilace s použitím parametrů USE.

Rozdělené a monolitické ebuildy mohou být volně míchany. Jediné omezení je, že monolitické ebuildy nemůžou být instalovány ve stejnou dobu jako, od nich odvozené, rozdělené ebuildy. V rozdělených ebuildech existují blokující depy (deps), které si to vynutí, tak můžete udělat cokoliv co vám přídání (emerge) umožní udělat.

Běžně však není důvod použít takové míchané konfigurace. Ve skutečnosti, kromě speciálních případů jako velmi pomalé překládané krabičky (mips), by jste měli použít rozdělené ebuildy pro vše co potřebujete.

Rozdělené ebuildy jsou rovněž výchozí ebuildy. Tím se myslí, že když nějáký další ebuild závisí na KDE aplikaci, bude chtít nainstalovat rozdělený ebuild. Nicméně, odpovídající monolitický ebuild rovněž splní takový dep, tak můžete emergovat monolitické ebuildy manuálně a potom emergovat ebuild, který na tom byl zavislý

Jak bylo dříve řečeno rozdělené ebuildy by mohli zabrat více času k emergování než monolitické, kvůli režiji rozbalovaní a spouštění konfigurace pro každý balík. Kompletní emerge kde-meta by mohlo trvat o 20-30% déle než klasické emerge kde, nepřijatelné v už tak dlouhé kompilaci.

Navíc, v současnosti rozdělené ebuildy vždy spouští make -f admin/Makefile.cvs (tím se myslí spuštění autoconf, automake, atd. a několika souvisejícíh kde-specifickým skriptů). To přidává další zpomalení přibližně stejného pořadí jako configure run.

Nakonec, rozdělené ebuildy potřebují rozbalit specifické soubory mimo velké „tarbally“. To je pomalejší než rozbalit vyhrazené, malé „tarbally“. Nicméně, vytvoření takových malích „tarballů“ pro „autotools-based“ (nástroje které se samy spustí zavedou atd.) buildy systému KDE 3.x je obtížné.

Je třeba zdůraznit, že s rozdělenými ebuildy a KDE aktualizačním kompilačním časem může být velice zredukován pouze aktualizovaním balíčku, který se aktuálně změnil. Výhody od takovýchto samostatných aktualizací často zastíní režiji způsobenou behem původní instalace.

Nakonec, instalování všeho z KDE dává smysl pouze pokud chcete prohlížet dostupné balíčky nebo nastavit multi-uživatelské prostředí; nicméně, většina lidí používá pouze několik z 300+ KDE dostupných aplikací. Kdokoliv kdo se opravdu stará o kompilační čas, to jsou zejména vlastnící starých počítačů, můžou získat více času při kompilaci vybráním instalačních balíčků, než aby ztratili režijní náklady.

Většina nebo dokonce všechno z rozdělených výkonových problémů ebuildů jsou přivázána k auto-nástrojům - autoconf, automake a dalších nástrojů, které zpravují ./configure;make;make install build systém v KDE 3.x.

KDE 4 přijme (pokud to ovšem můžem říci) kompletně nový build systém, který mezi dalšími věci vysoce zredukuje čas, ten vezme jen ekvivalent make -f admin/Makefile.common; ./configure. Doufejme, že to také udělá mnohem snažší vytvořit malé tarbally pro každý rozdělený ebuild snížením ceny generování tohoto ekvivalentu - konfiguračních skriptů (pokud nějákých).

Dříve, confcache bylo považováno jako cesta ke snížení ceny opakovaně běžících autoconf-generovaných konfiguračních skriptů. Confcache je metoda zapamatování (odložení do paměti cache) výsledku konfiguračních testů. Nicméně, pořád tady není implementace confcache ve stabilním (2.0) portage stromu. Dokonce, pokud se přidá v budoucnu, nemusí pro nás přijít dostatečně brzy,aby se mohla používat v KDE ebuildech; můžeme akorát počkat na KDE 4.

Jak bylo vysvětleno výše, né všechny aplikace jsou opravdu aktualizovány mezi hlavními KDE vydáními (releases), a tak né všechny aplikace obdrží novou verzi ebuildu. Například, libkdenetwork nebyl aktualizován v 3.5.0_beta2, takže nejnovější dostupný ebuild s tímto vydáním (release) byl 3.5_beta1.

Takto je to uděláné čistě k omezení kompilačního času během aktualizace. Jesliže jsme udělali ebuild libkdenetwork-3.5.0_beta2, měl by instalovat přesně ty samé soubory jako ebuild 3.5_beta1. Rozdílné závislosti jsou aktualizovány tak aby pracovaly správně. (např. žádný ebuild nebude závislý na libkdenetwork-3.5.0_beta2).

DO_NOT_COMPILE je vnitřní proměnná prostředí KDE build systému. To dovoluje výběrové vypnutí podadresářů z kompilace. Někteří lidé měli ve zvyku používat to ke kompilaci subsetů monolitických KDE ebuildů. Například, spuštěním DO_NOT_COMPILE=konqueror emerge kdebase by se nainstaloval kdebase bez konqueror aplikace.

Nicméně, DO_NOT_COMPILE nebyla nikdy určená aby se použila k zásahu do operace balíčků automatizovaného manažeru buildů. To nefunguje, může zničit váš systém, a nebylo to nikdy podporováno. Žádáme každého aby se vyvaroval použití této proměnné.

Tady je částečný seznam problémů s DO_NOT_COMPILE:

• Kompletně rozbije hledání závislostí portage. Portage neví o DO_NOT_COMPILE, a myslí že celkový monolitický balík byl nainstalován a že může uspokojit další depy balíčků. To může spůsobit, že další balíčky se nebudou emergovat nebo nepoběží.
• Vyvíjí tlak na uživatele aby znali jména a myšlení všech rozdílných existujícich podadresářů KDE modulů. Velmi málo uživatelů to ví, dokud nejsou vývojáři KDE, tak nemůžou řádně používat DO_NOT_COMPILE.
• KDE modul podadresářů může mít vzájemnou závislost mezi nima, vyžadujíce částečné build pořadí, jiný adresář aby byl přítomný dokonce i když nebyl nainstalován a tak dále. Vkládáme mnoho práce do rozdělených ebuildů aby v tomto ohledu správně fungovali. DO_NOT_COMPILE není vůbec dostatečný nástroj k dosáhnutí stejného výsledku, dokonce i s danými potřebnými znalostmi na uživatelské straně. Jediná věc, kterou s tím můžete dělat je vyřadit několik málo aplikací z překládání. Je prakticky nemožné použít to k instalaci pouze několika málo vybraných aplikací z modulů jako kdebase nebo kdepim.
• Jestliže jsem včera instaloval kmail a dnes chci přidat korn, použití DO_NOT_COMPILE způsobí roněž i rekompilaci kmailu. Tím se myslí, že DO_NOT_COMPILE je vždycky mnohem pomalejší než rozdělené ebuildy.
• DO_NOT_COMPILE nemůže být použit k udělání předkompilovaných balíčků (jako GRP) obsahující samostatné KDE aplikace.

Překvapivě, tato otázka žádá hodně. Jsem rád, že uživatelé jsou tak ohleduplný k nám udržbářům. Dovolte mi vzít tuto příležitost k vašemu ujištění, že se věnujeme rozděleným ebuildům pouze z naší svobodné vůle; že věříme že budeme schopni dobře pokračovat v udržovaní; a že není žádná šance vymluvit se z toho :-)

Pro úplnost bych měl zmínit že údržbáři z jiných archů si v důsledku stěžovali na zvýšené pracovní zatížení ohledně testování a klíčování slov tak hodně oddělených ebuildů. Pracujeme na vyřešení a to je hlavní důvod proč jsou vlastně monolitické ebuildy stále dostupné pro KDE 3.4.

Zamýšlíme to udělat až nakonec. Nicméně, monolitické a rozdělené ebildy budou pro všechny KDE 3.x releases.

Pokud dáváte přednost monolitickým ebuildům před rozdělenými, prosím řekněte nám vaše důvody.

No, především, jestli znáte hledaný balíček, který příjde s kdebase, můžete stále emerge kdebase-meta, s větším počtem stejných výsledků, jako když jste emergovali monolitické kdebase. Věci se ve skutečnosti nestali horšími kvůli rozděleným ebuildům ;-)

Samozřejmě, všechny obvyklé cesty k nalezení balíčku také použijte. Jak by jste našli Váš ebuild, kdyby to byla Gnome aplikace? Jako minimum, musíte znát jméno aplikace kterou hledáte.

Situace by se mohla, snad, zlepšit uvedením nějákých více -meta ebuildů. Jsou pouze seznamem závislostí, tak nás nic nestojí. Ale to zatím nebylo rozhodnuto. Také by bylo pěkné mít nastavenou funkčnost Portage před tím než to uděláme rozsáhlejší.

Cílem je vypsat všechny rozdělené ebuildy odvozených od, řekněme, kdebase monolitického ebuildu. Opět, řádná implementace (jako je GLEP 21) by toto udělala triviální věcí. Nicméně dneska, se musíte do určité míry spojit s detaily implementace KDE eclasses. Tak, pokud používáte nějáký z těchto kroků ve skriptů, tak to není pro soukromé účely ale řekněte nám o tom.

kde-fukce.eclass definují funkce nazývané get-paren-package() a get-child-packages(), které udělají překlad za vás. Tyto dvě funkce jsou správnou cestou k provedení tohoto úkolu z ebuildu nebo z externího bash skriptu. Příklad:

$ function die() { echo $@; } # report chyb
$ source /usr/portage/eclass/kde-functions.eclass
$ get-parent-package konqueror # nechce-li fungovat, musíte specifikovat plné jméno
Package konqueror not found in KDE_DERIVATION_MAP, please report bug # chyba
$ get-parent-package kde-base/konqueror # plně kompetentní jméno balíku
kde-base/kdebase # výsledek vypsaný
$ get-child-packages kde-base/kdebase
 # (následuje dlouhý seznam balíčků)

Pokdu váš skript není v bash, můžete grep kde-functions.eclass k vytáhnutí (víceřákově) definicí proměnné KDE_DERIVATION_MAP, která výše uvedené funkce používá. Tato proměnná obsahuje mezerou oddělený seznam slov a každé dvě za sebou jdoucí slova mapují rodičovský (parent) balíček k potomku (child) rozděleného ebuildu.