De KDE gesplitste ebuilds HOWTO

1.  De gesplitste KDE Ebuilds

Wat zijn ze?

Tot januari 2005 waren de monolithische ebuilds de enige KDE ebuilds in Portage. Dat wil zeggen dat er slechts 15 KDE ebuilds waren (kdebase, kdenetwork, ...) en elke ebuild installeerde een hoop applicaties die in feite niet van elkaar afhankelijk waren. Dit was duidelijk geen optimale situatie en niet erg "Gentoo", maar werd lange tijd getolereerd.

De nieuwe gesplitste ebuilds (konqueror, kmail, ...) zetten de situatie recht door aparte ebuilds te voorzien voor alle KDE-applicaties. Dit gaf ons een totaal van 330 nieuwe ebulids in de categorie kde-base.

We voorzien nog steeds monolithische ebuilds voor KDE 3.5, en ze kunnen samen met de gesplitste gebruikt worden. De gesplitste ebuilds zijn nu wel de standaard en voor KDE 4.0 zullen er geen monolithische meer zijn.

Tenslotte moet er ook vermeld worden dat er gesplitste ebuilds zijn voor KOffice. Deze voorzien kword, kugar, enz. als gescheiden pakketten.

Hoe de gesplitste ebuilds installeren?

De laatste stabiele release op het moment van dit schrijven is 3.5.2. De laatste onstabiele (~arch) is 3.5.5. Gesplitste en monolithische ebuilds voor beide opleveringen zijn in Portage beschikbaar.

• Om een bepaald pakket zoals kmail te installeren, gebruik je heel eenvoudig emerge kmail.
• Om de basis van de KDE-omgeving die je toelaat je aan te melden in een minimale KDE-sessie, gebruik je emerge kdebase-startkde.
• Om hetzelfde te hebben als één van de monolithische pakketten, bijvoorbeeld alle pakketten uit kdebase via gesplitste ebuilds, gebruik je emerge kdebase-meta (of kdepim-meta, ...). Als je absoluut alle beschikbare gesplitste KDE ebuilds wil, typ je emerge kde-meta.

Hoe upgraden van de monolithische naar de gesplitste ebuilds?

Als je nu KDE 3.3.x hebt, kan je emerge kde-meta gebruiken om de 3.5.x ebuilds te installeren, zonder je bestaande installatie te verstoren.

Als je nu de KDE 3.4.x of 3.5.x monolithische ebuilds geïnstalleerd hebt, moet je ze desinstalleren voor je de gesplitste kan installeren. Dit proces kan om de beurt voor elke monolithische ebuild gebeuren, je moet ze niet allemaal in één keer desinstalleren.

Als je twijfelt, denk er dan aan dat er blokkerende afhankelijkheden zitten tussen elke monolithische ebuild en de gesplitste ebuilds die eruit afgeleid zijn. Portage laat je niet toe een illegale status te creëren, dus elke installatie of desinstallatie die Portage toelaat, is goed.

Voordelen van de gesplitste ebuilds

Hier volgt een korte lijst van wat we winnen door de overschakeling naar gesplitste ebuilds:

• De meeste KDE pakketten worden niet aangepast tussen twee kleine opleveringen van KDE. De update van 3.3.1 naar 3.3.2 bijvoorbeeld, wijzigde minder dan 100 pakketten van de 320. Gesplitste pakketten laten ons toe enkel nieuwe ebuilds te maken voor de pakketten die effectief gewijzigd zijn, wat (in dit voorbeeld) meer dan twee derden van de compilatietijd bespaart bij een upgrade.
• Patches hebben gewoonlijk maar effect op een specifiek pakket. Met gesplitste ebuilds kunnen ze sneller getest, goedgekeurd en gecommit worden, en de ontwikkelaars hebben minder te doen. Bovendien zal de gebruiker minder tijd nodig hebben bij de upgrade. Dit is vooral belangrijk bij beveiligingsupdates.
• Gebruikers van andere desktops en kleinere Vensterbeheerders kunnen nu de KDE-applicaties installeren die ze leuk vinden, zonder de grote overhead van de rest zoals kdebase of kdepim.
• Gebruikers kunnen de pakketten die ze geïnstalleerd hebben fijnstellen. Redenen waarom je dit wil doen:
  • Je zit in met de compilatietijd. emerge kdebase kdepim kdenetwork duurt veel te lang wanneer je enkel konqueror, kmail en kopete nodig hebt. Bovendien, compilatietijd is geld.
  • Je zit in met schijfgebruik. Elke ongebruikt pakket is een aantal MB in de poriën van je schijfsectoren. Een schijf met meer vrije ruimte, ademt vrij; het is een snelle, blije schijf.
  • Je zit in met de veiligheid van je systeem. Alle geïnstalleerde software is een potentiële bron van gevaar. Er is geen excuus voor ongebruikte software die ergens rondslingert.
  • Je bewandelt braaf het Gentoo Pad (en) en je kan er (zoals wij) niet tegen dat pakketten gebundeld worden en aan de gebruiker opgelegd worden.
• Tenslotte laten de gesplitste ebuilds ons toe meer flexibiliteit te bieden wat betreft USE-vlaggen bij compilatie.

Samenwerking van gesplitste en monolithische ebuilds

Gesplitste en monolithische ebuilds kunnen vrij gemengd worden. De enige beperking is dat een monolithische ebuild niet geïnstalleerd kan worden samen met een gesplitste die ervan is afgeleid. Er zijn blokkerende afhankelijkheden die dit afdwingen, je kan dus alles doen wat emerge je toelaat.

Normaal gezien is er geen enkele reden om zo'n gemengde configuratie te gebruiken. In feite zou je altijd de gesplitste ebuilds moeten gebruiken, behalve voor uitzonderlijke gevallen zoals heel traag compilerende systemen (mips).

De gesplitste ebuilds zijn ook de standaard ebuilds. Dit wil zeggen dat een andere ebuild die afhangt van een KDE-applicatie de gesplitste ebuild zal willen installeren. De overeenkomstige monolithische ebuild zal echter ook die afhankelijkheid verzorgen. Je kan dus manueel de monolithische ebuild installeren en daarna de ebuild die ervan afhangt.

2.  Performantieperikelen

Waarom gesplitste ebuilds traag zijn

Het werd al eerder gezegd dat gesplitste ebuilds veel meer tijd zouden nodig hebben om geïnstalleerd te worden dan de monolithische, door de overhead van het uitpakken en uitvoeren van ./configure van elk pakket. Een volledige emerge kde-meta zou 20 à 30% langer kunnen duren dan een klassieke emerge kde, onaanvaardbaar bij een reeds lang durende compilatie.

Verder voeren de gesplitste ebuilds op die moment altijd make -f admin/Makefile.cvs uit (dit wil zeggen een uitvoering van autoconf, automake, ... en verschillende KDE-gerelateerde scripts). Dit veroorzaakt een bijkomende vertraging van ongeveer dezelfde grootte als de configuratierun.

Tenslotte moet een gesplitste ebuild uitgepakt worden uit een grote tarball. Dit is trager dan het uitpakken van een aangepaste, kleine tarball. Het aanmaken van zulke kleine tarballs voor het op autotools gebaseerde systeem van KDE 3.x is echter moeilijk.

Het is de moeite om hier nogmaals te herhalen dat met gesplitste ebuilds de compilatietijd bij een KDE-upgrade sterk verkort kan worden door enkel de gewijzigde pakketten te upgraden. Het voordeel van zo'n enkele update overschaduwt meestal de overhead opgelopen bij de oorspronkelijke installatie.

Tenslotte is het installeren van alle KDE-pakketten enkel nodig indien je ze wil ontdekken of wanneer je een multi-gebruikersomgeving opzet. De meeste mensen gebruiken echter slechts een fractie van de meer dan 300 beschikbare KDE-pakketten. Iedereen die zich iets van de compilatietijd aantrekt, kan meer tijd winnen door het selectief installeren van de nodige pakketten dan ze tijd zouden verliezen door de bijkomende overhead.

Hoe gesplitste ebuilds sneller worden gemaakt

De meeste of zelf alle performantieperikelen van de gesplitste ebuilds hangen samen met autotools met name autoconf, automake en andere hulpmiddelen die het ./configure;make;make install bouwsysteem van KDE 3.x beheren.

KDE 4 zal (voor zover we op dit moment weten) een volledig nieuw bouwsysteem bevatten, dat onder andere de tijd die het oude bouwsysteem nodig heeft met make -f admin/Makefile.common; ./configure, sterk zal verkorten. Hopelijk zal het daarbij ook gemakkelijker zijn om een kleine tarball voor elke ebuild te voorzien door de kost te verlagen die het genereren van de bijhorende configuratiescripts meebrengt.

Eerder al is er overwogen om confcache te gebruiken om de kost van het herhaaldelijk uitvoeren van door autoconf gegenereerde configuratiescripts te verlagen. Confcache is een manier om de resultaten van de configuratietests op te slaan. Er is echter nog confcache-implementatie in de stabiele (2.1) Portage-boom. Zelfs indien die in de toekomst wordt toegevoegd, zou het te laat kunnen zijn om het in de KDE ebuilds te gebruiken; we zouden kunnen wachten op KDE 4.

3.  Gesplitste ebuilds - veel gestelde vragen (FAQ)

Waarom missen sommige pakketten de nieuwe ebuildversies?

Zoals hierboven uitgelegd worden niet alle programma's aangepast bij kleine KDE opleveringen, en dus krijgen ze niet allemaal nieuwe ebuild versies. Bijvoorbeeld, libkdenetwork was niet aangepast in 3.5.0_beta2 dus de nieuwste ebuild beschikbaar voor die oplevering was 3.5_beta1.

Dit wordt enkel gedaan om de compilatietijd tijdens een upgrade te verminderen. Als we een libkdenetwork-3.5.0_beta2 ebuild hadden gemaakt, zou het exact dezelfde bestanden als de 3.5_beta1 ebuild hebben geïnstalleerd. De verschillende afhankelijkheden worden geupdate om correct te werken. Dit wil zeggen dat geen enkele ebuild van libkdenetwork-3.5.0_beta2 zal afhangen, want die bestaat niet.

Is dit nog niet mogelijk met DO_NOT_COMPILE?

DO_NOT_COMPILE is een omgevingsvariabele die intern in het KDE bouwsysteem wordt gebruikt. Het laat toe selectie submappen bij compilatie uit te sluiten. Sommige mensen gebruikten het om subsets van monolithische KDE ebuilds te compileren. Het uitvoeren van DO_NOT_COMPILE=konqueror emerge kdebase zou dus kdebase installeren zonder het programma konqueror.

DO_NOT_COMPILE was echter nooit bedoeld als interface voor de automatische bouw via een pakketbeheerder. Het werkt niet, het kan je systeem stuk maken en het werd nooit ondersteund. We vragen iedereen om dit niet te gebruiken.

Hier volgt een onvolledige lijst van problemen met DO_NOT_COMPILE:

• Het maakt de afhankelijkheidscontroles van Portage volledig stuk. Portage weet niets over DO_NOT_COMPILE en denk dat het hele monolithische pakket geïnstalleerd is en voldoet voor de afhankelijkheden van andere pakketten. Dit kan ervoor zorgen dat andere pakketten niet geïnstalleerd of niet uitgevoerd kunnen worden.
• Het dwingt de gebruiker om de namen en betekenissen van alle verschillende bestaande submappen van de KDE-modules te kennen. Weinig of geen gebruikers kennen deze, tenzij de KDE-ontwikkelaars, dus ze kunnen DO_NOT_COMPILE niet gepast gebruikten.
• De submappen van de KDE-modules kunnen onderling afhankelijkheden hebben, een bepaalde bouwvolgorde eisen of willen een bepaalde map aanwezig hebben, ook al moet ze niet geïnstalleerd worden, enzovoort. We stoppen heel veel werk in de gesplitste ebuilds om ze correct te doen werken. DO_NOT_COMPILE is geen goed hulpmiddel om dezelfde resultaten te krijgen, zelfs als de gebruiker genoeg kennis bezit. Het enige dat je ermee kan doen is enkele programma's uit te sluiten bij het compileren. Het is praktisch onmogelijk om het te gebruiken om slechts enkele programma's uit modules als kdebase of kdepim te installeren.
• Als ik gisteren kmail installeerde en ik wil vandaag korn erbij, zal ik bij gebruik van DO_NOT_COMPILE kmail opnieuw compileren. Op deze manier is DO_NOT_COMPILE altijd trager dan gesplitste ebuilds.
• DO_NOT_COMPILE kan niet gebruikt worden om geprecompileerde pakketten (zoals GRP) te maken die één enkel KDE-programma bevatten.

Wordt er geen te zware druk gezet op de Gentoo KDE beheerders?

Verrassend genoeg wordt deze vraag dikwijls gesteld. Ik ben blij dat de gebruikers zo bezorgd zijn over de beheerders. Laat dit het moment zijn waarop ik jullie kan verzekeren dat we uit vrije wil voor de gesplitste ebuilds hebben gekozen en dat we geloven dat deze kunnen blijven onderhouden. Bovendien is er geen enkele kans om ons nog om te praten... :-)

Voor de volledigheid wil ik ook vermelden dat de beheerders van andere architecturen geklaagd hebben over de bijkomende werklast bij het testen van zoveel verschillende ebuilds. We werken eraan dit probleem op te lossen en dit is de belangrijkste reden waarom monolithische ebuilds nog beschikbaar zijn voor KDE 3.5.

Gaan de oude monolithische ebuilds verwijderd worden?

We zijn dit in de toekomst van plan. Er zullen echter monolithische en gesplitste ebuilds zijn voor alle KDE 3.x opleveringen.

Als je monolithische ebuilds verkiest boven gesplitste, vertel ons dan alsjeblief waarom.

Er zijn teveel ebuilds! Hoe vind ik diegene die ik nodig heb?

Allereerst als je pakket kwam met kdebase, kan je nog steeds emerge kdebase-meta gebruiken, met dezelfde resultaten als de installatie van de monolithische kdebase. Er is dus niet op achteruitgegaan sinds de gesplitste ebuilds.

Natuurlijk gelden ook alle gebruikelijke manieren om een pakket te vinden. Hoe zou je een ebuild vinden als het een Gnome-programma was? Je moet minstens de naam kennen van het programma dat je zoekt.

De situatie zou misschien verbeterd kunnen worden door wat meer -meta ebuilds te voorzien. Deze bevatten slechts een lijst van afhankelijkheden, dus kosten ons niets. Dit is nog niet beslist. Het zou interessant zijn om eerst de Portage sets functionaliteit te hebben, voor we dit uitgebreid beginnen doen.

Hoe kan ik alle ebuilds die afgeleid zijn van een bepaald pakket uitlijsten of desinstalleren?

Het doel is hier om alle gesplitste ebuilds uit te lijsten die afgeleid zijn van bijvoorbeeld de kdebase monolithische ebuild. Een geschike implementatie (zoals GLEP 21) zou dit triviaal maken. Vandaag moet je je echter vertrouwd maken met de details van KDE's eclassimplementatie. Als je dus één van deze benaderingen gebruikt in een script dat niet privé is, laat het ons weten.

De kde-functions.eclass definieert functies genaamd get-parent-package() en get-child-packages() die de vertaling voor jou doen. Deze twee functies zijn de correcte manier om deze taak voor een ebuild te doen in een extern bashscript. Hier is een voorbeeld:

$ function die() { echo $@; } # om fouten te rapporteren
$ source /usr/portage/eclass/kde-functions.eclass
$ get-parent-package konqueror # zal niet werken, je moet de volledige naam geven
Package konqueror not found in KDE_DERIVATION_MAP, please report bug # fout getoond
$ get-parent-package kde-base/konqueror # volledige pakketnaam
kde-base/kdebase # resultaat getoond
$ get-child-packages kde-base/kdebase
 # (lange lijst van pakketten wordt hier getoond)

Als je script niet in bash is, kan je met grep de (meerlijnige) definitie van de variabele KDE_DERIVATION_MAP die hierboven gebruikt wordt, uit kde-functions.eclass halen. Deze variabele bevat een door witruimte gescheiden lijst van woorden. Elk paar van twee opeenvolgende woorden mappen een ouderpakket op een kindpakket nl. een gesplitste ebuild.

The contents of this document are licensed under the Creative Commons - Attribution / Share Alike license.