Das KDE Split Ebuilds HOWTO

1.  Die KDE 'split' Ebuilds

Was sie ausmacht

Bis Januar 2005 waren die monolithischen Ebuilds die einzigen KDE-Ebuilds in Portage. Dazu ist zu sagen, dass es damals nur 15 Ebuilds (kdebase, kdenetwork, ...) gab und jedes einzelne installierte viele Anwendungen, die aber selbst nicht voneinander abhängig waren. Das war offensichtlich eine suboptimale Situation und nicht besonders Gentoo-isch, aber es wurde für eine lange Zeit toleriert.

Die neuen 'split' Ebuilds (für Konqueror, Kmail, ...) verbesserten die Situation, indem sie separate Ebuilds für alle separaten KDE Anwendungen boten. Das gab uns eine Summe von etwa 330 neuen Ebuilds in der kde-base Kategorie.

Wir bieten noch immer die monotlithischen Ebuilds für KDE 3.5 (bis 3.5.9) an, und sie bieten alles, was auch die 'split' Ebuilds bieten. Jedoch sind die 'split' Ebuilds nun der neue Standard, und nach KDE 3.5.9 wird es keine monolithischen Ebuilds mehr geben.

Schließlich sollte noch erwähnt werden, dass es auch 'split' Ebuilds für KOffice gibt. Diese stellen kword, kugar, usw. als separate Pakete zur Verfügung.

Wie installieren Sie die 'split' Ebuilds

Die aktuellste stabile KDE Version, zum Zeitpunkt der Erstellung dieses Dokuments, ist 3.5.9. Die aktuellste unstabile (~arch) Version ist 3.5.10. Sowohl die 'split' als auch die monolithischen Ebuilds sind dafür in Portage vorhanden. Das aktuellste 4.1.x Release ist auch im Portage-Baum vorhanden.

• Um ein spezielles Paket wie kmail zu installieren, reicht es, emerge kmail einzugeben.
• Um die KDE Basisumgebung, die es Ihnen erlaubt sich in eine minmale KDE Sitzung einzuloggen, zu installieren, emerge kdebase-startkde.
• Um schließlich das exakte Äquivalent eines der monolithischen Pakete zu installieren - zum Beispiel um alle Anwendungen, die in kdebase enthalten sind mit den 'split' Ebuilds zu installieren - können Sie emerge kdebase-meta (oder kdepim-meta, usw.) ausführen. Um absolut alle KDE 'split' Ebuilds zu installieren, verwenden Sie emerge kde-meta.

Wie aktualisieren Sie von monolithischen auf 'split' Ebuilds

Wenn Sie die KDE 3.4.x oder 3.5.x monolithischen Ebuilds installiert haben, müssen Sie sie zuerst deinstallieren bevor Sie die 'split' Ebuilds installieren können. Dieser Vorgang kann für jedes monolithische Ebuild wiederholt werden; Sie müssen nicht alles von KDE auf einmal deinstallieren.

Wenn Sie sich nicht sicher sind, seien Sie sich bewußt, dass es blockierende Abhängigkeiten zwischen den monolithischen und 'split' Ebuilds gibt. Portage wird es Ihnen nicht erlauben, einen ungültigen Zustand zu erstellen, also ist jede Installation oder Deinstallation, die erlaubt wird, OK.

Vorteile der 'split' Ebuilds

Hier ist eine kurze Liste, mit dem, was wir beim Wechsel zu den 'split' Ebuilds gewinnen:

• An den meisten KDE Paketen werden zwischen kleinen KDE Releases keine Änderungen vorgenommen. Zum Beispiel die Aktualisierung von 3.3.1 zu 3.3.2 änderte weniger als 100 von 320 Paketen. Die nun aufgespaltenen Pakete erlauben es uns, nur neue Ebuilds für die Pakete zu erstellen, die auch wirklich verändert wurden, was somit 2/3 (in diesem Beispiel) an Kompilierungszeit einspart.
• Patches betreffen für gewöhnlich ausgewählte Pakete. Mit den 'split' Ebuilds können diese schneller getestet, genehmigt und aufgenommen werden, und die Entwickler haben weniger zu tun; und, wie oben, der Benutzer muss weniger Zeit mit der Aktualisierung verbringen. Das ist im speziellen auch für Sicherheits-Updates relevant.
• Benutzer von anderen Desktopumgebungen und schlankeren Fenstermanagern können einige beliebte KDE Anwendungen - ohne den (ziemlich großen) überflüssigen Rest, wie kdebase oder kdepim - installieren.
• Benutzer können installierte Pakete noch weiter nach Ihren Bedürfnissen anpassen. Gründe für dies:
  • Sie interessieren sich für die Kompilierungszeit. emerge kdebase kdepim kdenetwork benötigt viel zu viel Zeit, wenn Sie nur konqueror, kmail und kopete installieren möchten. Nebenbei, CPU Zeit ist Geld... mancherorts.
  • Sie interessieren sich für den Festplattenverbrauch. Jedes unbenötigte Paket benötigt Platz auf Ihrer Festplatte.
  • Sie interessieren sich für die Systemsicherheit. Die gesamte installierte Software ist eine potentielle Quelle für verwundbare/angreifbare Stellen, und es gibt keine Entschuldigung für unbenötigte Software, die nur so herumliegt.
  • Sie folgen treu dem Gentoo Weg, und mögen keine gebündelten, dem Benutzer aufgezwungenen Pakete. (Mögen auch wir nicht.)
• Schließlich bieten die 'split' Ebuilds auch mehr Flexibilität gegenüber USE Flags während der Installation von Paketen.

Interoperabilität von 'split' und monolithischen Ebuilds

'Split' und monotlithische Ebuilds können miteinander frei vermischt werden. Die einzige Einschränkung ist die, dass monolithische Ebuilds nicht installiert werden können, wenn es bereits ein installiertes 'split' Ebuild gibt, das vom monolithischem abgeleitet werden kann. Es gibt in den Ebuilds blockierende Abhängigkeiten, die das erzwingen, somit können Sie alles tun, was Ihnen emerge erlaubt.

Jedoch gibt es für gewöhnlich keinen Grund eine gemischte Konfiguration zu verwenden. In der Tat, ausgenommen von wenigen speziellen Fällen wie sehr langsamen Maschinen (MIPS), sollten Sie für Ihren Gebrauch die 'split' Ebuilds verwenden.

Die 'split' Ebuilds sind auch die Standard Ebuilds. Das bedeutet, dass wenn eine andere Anwendung von KDE Anwendungen abhängig ist, wird es die 'split' Ebuilds installieren wollen. Jedoch wird das passende monolithische Ebuild auch die Abhängigkeit erfüllen, somit können Sie auch das monolithische Ebuild manuell installieren und dann das davon abhängige Ebuild installieren.

2.  Performanzüberlegungen

Warum sind 'split' Ebuilds langsam

Es wurde bereits gesagt, dass die 'split' Ebuilds viel mehr Zeit für die Installation benötigen werden als die monotlischen, wegen dem Mehr an Entpacken und Konfigurieren für jedes Paket. Ein vollständiges emerge kde-meta könnte 20-30% länger dauern als ein klassisches emerge kde, unakzeptabel in einem bereits langen Kompiliervorgang.

Darüberhinaus wird zurzeit bei den 'split' Ebuilds jedesmal make -f admin/Makefile.cvs ausgeführt (das bedeutet autoconf, automake u.s.w. und weitere KDE-spezifische Skripte werden ausgeführt). Das verlangsamt den Prozess um dieselbe Größe wie ein Konfigurationslauf.

Schließlich muss ein 'split' Ebuild bestimmte Dateien aus einem großen Tarball extrahieren. Das ist aber langsamer als einen passenden kleinen Tarball zu entpacken. Leider ist das Erstellen von solch kleinen Tarballs für das autotools-basierende System von KDE 3.x schwierig.

Es ist gut, nochmals hier zu erwähnen, dass mit den 'split' Ebuilds die Kompilierungszeit einer KDE Aktualisierung stark reduziert werden kann, indem man nur jene Pakete aktualisiert, die auch verändert wurden. Der Vorteil von solch einem einzelnen Update überschattet oft die überflüssigen Vorgänge während der ursprünglichen Installation.

Schließlich macht auch die Installation von allen KDE Paketen Sinn, wenn Sie die verfügbaren Pakete kennenlernen oder eine Mehrbenutzerumgebung aufsetzen möchten; jedoch verwenden die meisten Leute nur einige der 300+ verfügbaren KDE Anwendungen. Jeder, der sich für die Kompilierungszeit interessiert, wie Benutzer von älteren PCs, kann durch selektives Installieren von Paketen mehr Zeit gewinnen als verloren gehen würde durch die Installation aller Pakete.

Wie 'split' Ebuilds schneller gemacht werden

Die meisten oder sogar alle Performanzprobleme der 'split' Ebuilds sind auf autotools - autoconf, automake und andere Tools, die für das ./configure;make;make install Installationsystem von KDE 3.x verantwortlich sind, zurückzuführen.

KDE 4 hat ein ganz neues System zur Installation, cmake, aufgenommen, welches unter anderem die Zeit vom alten make -f admin/Makefile.common; ./configure weit unterbietet.

3.  'split' Ebuilds FAQ

Warum fehlen bei einigen 'split' Paketen die neuesten Ebuild Versionen?

Wie bereits erklärt wurde, nicht alle Anwendungen werden zwischen kleinen KDE Releases aktualisiert und somit erhalten auch nicht alle Anwendungen neue Ebuild Versionen. Zum Beispiel libkdenetwork wurde nicht in Version 3.5.0_beta2 aktualisiert, somit ist das aktuellste verfügbare Ebuild für dieses Release 3.5_beta1.

Das alles wird nur aus dem Grund getan, die Kompilierungszeit während eines Upgrades zu reduzieren. Wenn wir ein libkdenetwork-3.5.0_beta2 Ebuilds erstellt hätten, hätte es die exakt gleichen Dateien wie das Ebuild 3.5_beta1 installiert. Die verschiedenen Abhängigkeiten werden aktualisiert, damit alles korrekt funktioniert (d.h. kein Ebuild wird von libkdenetwork-3.5.0_beta2 abhängig sein).

Beachten Sie, dass Sie deshalb auch Pakete vorheriger Versionen von KDE demaskieren müssen, falls Sie maskierte Versionen von KDE installieren wollen und diese ebenfalls maskiert sind. Eventuell sollten Sie einen Blick auf diesen Bug werfen, um weitere Details zu erfahren.

Können wir das nicht bereits auch mit DO_NOT_COMPILE tun?

DO_NOT_COMPILE ist eine für das KDE-Buildsystem interne Umgebungsvariable. Sie erlaubt es selektiv Unterverzeichnisse vom Kompilierungsvorgang auszuschließen. Einige Leute verwenden sie, um Teile des monolithischen KDE-Ebuilds zu kompilieren. Zum Beispiel würde DO_NOT_COMPILE=konqueror emerge kdebase kdebase ohne die Anwendung konqueror installieren.

Jedoch war DO_NOT_COMPILE nie dafür ausgelegt sich in den Prozess eines automatisierten Vorgangs eines Paketmanagers einzumischen. Es funktioniert einfach nicht, es kann das System lahm legen, und es wurde nie unterstützt. Wir bitten jeden von der Verwendung dieses Konstrukts Abstand zu nehmen.

Here ist eine unvollständige Liste von Problemen mit DO_NOT_COMPILE:

• Es führt dazu, dass Portage Abhängigkeiten nicht korrekt nachvollziehen kann. Portage weiß nichts von DO_NOT_COMPILE und denkt, dass das ganze monolithische Paket installiert wurde und somit die Abhängigkeiten von anderen Paketen erfüllen kann. Das kann dazu führen, dass sich andere Pakete nicht installieren oder ausführen lassen.
• Es zwingt den Benutzer dazu, die Namen und Bedeutung von allen verschiedenen vorhandenen Unterverzeichnissen von den KDE Modulen zu kennen. Sehr wenige Benutzer kennen diese, wenn sie nicht gerade KDE-Entwickler sind, also können sie DO_NOT_COMPILE nicht korrekt verwenden.
• Unterverzeichnisse von KDE Modulen können selbst untereinander Abhängkeiten haben, die eine besondere Reihenfolge der Verarbeitung verlangen, ein anderes Verzeichnis benötigen auch wenn es nicht installiert werden muss, und so weiter. Wir haben viel Arbeit in die 'split' Ebuilds gesteckt, damit sie in diesem Zusammenhang korrekt arbeiten. DO_NOT_COMPILE ist nicht im Entferntesten ein ausreichend präzises Tool, dass dieselben Ergebnisse erreichen lässt, auch nicht mit ausreichend gegebenem Wissen auf der Benutzerseite. Das Einzige, was Sie damit machen können, ist ein paar Anwendungen vom Kompiliervorgang auszuschließen. Es ist praktisch unmöglich ein paar ausgewählte Anwendungen von Modulen wie kdebase oder kdepim damit zu installieren.
• Wenn ich gestern Kmail installiert habe, und heute möchte ich mit DO_NOT_COMPILE Korn hinzufügen, führt es dazu, dass Kmail auch nochmals kompiliert wird. Das bedeutet, DO_NOT_COMPILE ist immer langsamer als die 'split' Ebuilds.
• DO_NOT_COMPILE kann nicht dazu verwendet werden, um vorkompilierte Pakete (wie die GRP), die einzelne KDE Anwendungen beinhalten, zu installieren.

Führt das nicht zu sehr viel Arbeit für die Gentoo KDE Maintainer?

Diese Frage wird überraschenderweise oft gestellt. Ich bin froh, dass sich Benutzer so um uns Maintainer sorgen. Lassen Sie mich die Gelegenheit nutzen, um Ihnen zu versichern, dass wir uns den 'split' Ebuilds aus unserem freien Willen heraus angenommen haben; dass wir daran glauben, dass wir in der Lage sein werden, diese weiterhin gut verwalten zu können; und dass es keine Chance gibt, uns davon abzuhalten :-)

Der Vollständikeit halber sollte ich erwähnen, dass sich die Maintainer von anderen Architekturen sehr wohl über den erhöhten Aufwand was Testen und Keywording von so vielen separaten Ebuilds betrifft, beschwert haben. Wir arbeiten daran, und es ist auch ein Hauptgrund warum es monolithische Ebuilds noch immer für KDE 3.5 gibt.

Werden die alten (monolithischen) Ebuilds entfernt?

Wir haben vor, das früher oder später zu tun. Jedoch wird es sowohl monolithische als auch 'split' Ebuilds für alle KDE 3 Releases bis 3.5.9 geben. Für KDE 3.5.10 sowie folgende Versionen und KDE4 bieten wir keine monolithischen Ebuilds mehr an.

Wenn Sie die monolithischen den 'split' Ebuilds gegenüber vorziehen, bitte teilen Sie uns Ihre Gründe mit.

Es gibt zuviele Ebuilds! Wie soll ich das finden, was ich brauche?

Nun gut, zu allererst wenn Sie wissen, dass das Paket nach dem Sie suchen in kdebase enthalten war, dann können Sie immer noch emerge kdebase-meta ausführen, um so ziemlich das selbe Resultat zu erhalten wie wenn Sie das monolithische kdebase installieren würden. Deswegen haben sich eigentlich die Dinge wegen der 'split' Ebuilds nicht verschlechtert.

Natürlich können Sie noch immer auf demselben Weg ihre Pakete finden. Wie würden Sie Ihr Ebuild finden, wenn es sich um eine Gnome Anwendung handelt? Zumindest müssen Sie wissen wie die Anwendung heißt nach der Sie suchen.

Die Situation könnte vielleicht verbessert werden, wenn mehrere -meta Ebuilds zur Verfügung gestellt werden. Sie sind hauptsächlich eine Liste von Abhängigkeiten, somit bereiten sie für uns keine großen Umstände. Darüber wurde aber noch nichts beschlossen. Auch wäre es nett, wenn Portage Mengenfunktionalität bieten würde, bevore wir das ausbreiten.

Wie kann ich alle 'split' Ebuilds, die von einem gegebenen Paket abgeleitet werden können, auflisten/deinstallieren?

Das jetzige Ziel ist es, eine Liste aller 'split' Ebuilds, die z.B. vom kdebase monolithischem Ebuild abgeleitet werden können, zu bekommen. Wieder einmal würde eine passenden Implementierung (wie in GLEP 21) die Sache sehr einfach machen. Momentan müssen Sie aber einen Einblick in die Implementierung der KDE eclasses erlangen. Also, wenn Sie irgendeinen dieser Ansätze in einem Skript, das nicht für den privaten Gebrauch alleine ist, verwenden, lassen Sie uns davon wissen.

kde-functions.eclass definiert Funktionen wie get-parent-package() und get-child-packages(), die die Übersetzung für Sie vornehmen. Diese zwei Funktionen sind der korrekte Weg, um diese Aufgaben von einem Ebuild oder einem externen Bashskript aus zu lösen. Hier ist ein Beispiel:

$ function die() { echo $@; } # um Fehler auszugeben
$ source /usr/portage/eclass/kde-functions.eclass
$ get-parent-package konqueror # wird nicht funktionieren, sie
müssen einen vollen Namen angeben
Package konqueror not found in KDE_DERIVATION_MAP, please report bug #
Ausgabe des Fehlers
$ get-parent-package kde-base/konqueror # voll qualifizierter
Paketname
kde-base/kdebase # Ausgabe des Ergebnis
$ get-child-packages kde-base/kdebase
(Ausgabe einer langen Liste von Paketen)

Wenn Ihr Skript nicht in Bash ist, können Sie ein grep auf die kde-functions.eclass machen, um die (mehrzeilige) Definition der Variable KDE_DERIVATION_MAP, die die zuvor genannten Funktionen verwendet, zu erhalten. Diese Variable enthält eine durch Leerzeichen getrennte Liste an Wörtern, und jede zwei aufeinanderfolgenden Wörter bilden ein Paket auf ein abgeleitetes 'split' Ebuild ab.

Die Inhalte dieses Dokuments sind unter der Creative Commons - Namensnennung / Weitergabe Lizenz lizenziert.