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.
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.
Hier ist eine kurze Liste, mit dem, was wir beim Wechsel zu den 'split' Ebuilds gewinnen:
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.
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.
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:
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.
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:
Befehlsauflistung 3.1: Beispiel der Verwendung der kde-functions Funktionen: |
$ 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.