emerge kmail (KDE Meta ebuilds verwenden)

[Earthwings]

DISCLAIMER: Benutzung auf eigene Gefahr

Ein häufig zu hörender Kritikpunkt an der Installation von KDE unter Gentoo ist die lange Zeit, die dessen Installation in Anspruch nimmt. Während der KDE Installation werden viele Pakete installiert, die von den meisten Benutzern nie benutzt werden - es liegt nahe, eben diese Pakete gar nicht erst zu installieren. Bisher konnte man sich mit der "DO_NOT_COMPILE" Variablen behelfen, doch dieser Ansatz hat einige Schwächen.

Mit den KDE Metaebuilds soll das einfacher werden. Anstatt viele Programme auf einmal in kdemultimedia, kdepim etc. zu installieren, bekommt jedes Programm ein eigenes ebuild. Will man beispielsweise nur kmail, kword und konqueror benutzen, reicht ein

Code: Select all

emerge konqueror kmail kword

Die traditionelle vollständige KDE-Installation ist weiterhin durch "emerge kde-meta" verfügbar, koffice entsprechend durch "emerge koffice-meta".

Installation
Noch einmal: Das ist kein offizielles gentoo.org Projekt. Es ist nicht stabil. Installation auf eigene Gefahr.

Code: Select all

mkdir -p /usr/local/kde-meta
cd /usr/local

1. Möglichkeit: Herunterladen mit subversion

Code: Select all

emerge -n subversion
svn checkout svn://svn.berlios.de/kde-metaebuilds/trunk/ kde-meta

Alternative: Dateien manuell herunterladen

Code: Select all

wget http://download.berlios.de/kde-metaebuilds/kde-metaebuilds-6.tar.bz2
tar -xvjf kde-metaebuilds-6.tar.bz2
mv dist kde-meta

Anschließend muss man /usr/local/kde-meta als PORTDIR_OVERLAY in make.conf eintragen.

Code: Select all

nano -w /etc/make.conf

Bei mir sieht das anschließend so aus:

Code: Select all

[...]
PORTDIR_OVERLAY="/usr/local/portage /usr/local/gentoo-de /usr/local/kde-meta"
[...]

Probieren, ob alles geklappt hat:

Code: Select all

emerge knode -pv

Auf stabilen System sollte man eine derartige Fehlermeldung bekommen:

Code: Select all

# emerge knode -pv

These are the packages that I would merge, in order:

Calculating dependencies
!!! All ebuilds that could satisfy "knode" have been masked.
!!! One of the following masked packages is required to complete your request:
- kde-base/knode-3.3.1 (masked by: ~x86 keyword)

For more information, see MASKED PACKAGES section in the emerge man page or
section 2.2 "Software Availability" in the Gentoo Handbook.

Die Pakete müssen einzeln in /etc/portage/package.keywords eingetragen werden. Wer faul ist, kann das z.B. von epo erledigen lassen.

Aktualisierung
Wer die Dateien per svn heruntergeladen kann, kann zum Updaten folgenden Befehl verwenden:

Code: Select all

svn update /usr/local/kde-meta

Vorteile
+ Zeitersparnis durch Weglassen ungenutzter Programme
+ mehr Festplattenplatz, wenn nicht alle Programme installiert werden

Nachteile
- längeres Installieren durch mehrfaches "configure" (Abhilfe: confcache)
- erhöhte Komplexität, dadurch potentiell mehr Bugs. Noch nicht ausreichend getestet.
- manuelles Updaten der ebuilds notwendig.

Lesenswert
[1] http://kde-metaebuilds.berlios.de/
[2] http://www.gentoo.org/news/en/gwn/20041 ... letter.xml

TODO (für diesen Tipp)
- confcache
- prepackaged Makefiles
- xdeltas (Downloadmenge reduzieren)

[sirro]

Die Pakete müssen einzeln in /etc/portage/package.keywords eingetragen werden. Wer faul ist, kann das z.B. von epo erledigen lassen.

Wie das nunmal so ist, hab ich den Thread just in dem Moment entdeckt in dem ich gestern schon alles eingetragen hatte

Uebersehe ich was oder hat eigentlich keins der kleineren Pakete (kate, kregexpedit etc.) eine Abhaengigkeit von irgendeiner kdelib? Fehlt die noch?

[astaecker]

Ich brauchte zum Kompilieren ein installiertes "kdelibs". Insofern sind schon die meisten Bibliotheken verfügbar.

[sirro]

Ich brauchte zum Kompilieren ein installiertes "kdelibs".

OK, das hab ich mir gedacht. Bei mir waren die Libs ja eh schon vorhanden...

[hothead]

Hi,
hat jemand ne Ahnung welches ebuild ich brauche um pop3 bei kmail zum laufen zu bekommen? - Hab nur die kdelibs aus dem normalen Portage tree installiert und alles weiter der kde mit den kde-meta ebuilds emerged.
Wenn ich versuche bei kmail meine emails abzurufen bekomme ich folgende Meldung:

Code: Select all

Prozess pop3 lässt sich nicht starten 

Würde mich über Hilfe freuen.

Ruben

[Earthwings]

kdebase aus Portage hast du nicht zufällig auch installiert?

[hothead]

ne, hab ich doch geschrieben. ich dachte, es lässt dass sich gerade die ganzen packete aus kdebase gut einzeln installieren lassen, doch da habe ich mich wohl getäuscht.
kennt hier jemand eine gute seite, auf der die ganzen funktionen der einzelnen programme der kde meta-ebuilds erklärt sind. so eine referenz würde einige ausprobiererei ersparen.

ruben

[Earthwings]

kennt hier jemand eine gute seite, auf der die ganzen funktionen der einzelnen programme der kde meta-ebuilds erklärt sind. so eine referenz würde einige ausprobiererei ersparen.

Gibt es afaik nicht (was genau meinst du mit Funktionen?). Schick doch mal ne Mail an die Mailingliste wegen des Fehlers mit pop3.

[shermann]

DISCLAIMER: Benutzung auf eigene Gefahr

Ein häufig zu hörender Kritikpunkt an der Installation von KDE unter Gentoo ist die lange Zeit, die dessen Installation in Anspruch nimmt. Während der KDE Installation werden viele Pakete installiert, die von den meisten Benutzern nie benutzt werden - es liegt nahe, eben diese Pakete gar nicht erst zu installieren. Bisher konnte man sich mit der "DO_NOT_COMPILE" Variablen behelfen, doch dieser Ansatz hat einige Schwächen.

Ob das so schlecht ist, was Gentoo gemacht hat (komplette KDE Ebuilds) wage ich zu bezweifeln.
Ich kenne die ganze Sch**sse von RedHat und div. anderen Binär Distributionen, die KDE komplett aufgesplittet haben und das ist der reinste Driss. Man weiss einfach nicht, was man installieren soll, und zwar genau dann, wenn man den Namen des Packages nicht kennt.

IMHO wäre es sinnvoller, die USE Flags vielleicht auch auf KDE anzuwenden, vielleicht nicht mit den global use flags, dann eher mit KDE spezifischen USEFlags.
Die Sourcepackete muessen sowieso geladen werden, und z.B. ein

Code: Select all

KDE_USE="kdenetwork-kmail kdenetwork-knode kdegraphics-kprovray"

in der make.conf ist wesentlich eleganter als

Code: Select all

# emerge search kde-|less
# [...RESULT...]
# emerge <kde-package>

Noch eleganter wird es, wenn man aus dem komplett Packet div. virtuals machen könnte, um zum Beispiel: virtual/min-kde virtual/mid-kde virtual/max-kde virtual/gentoo-kde

My 2Cent

\sh

[Earthwings]

Ob das so schlecht ist, was Gentoo gemacht hat (komplette KDE Ebuilds) wage ich zu bezweifeln.
Ich kenne die ganze Sch**sse von RedHat und div. anderen Binär Distributionen, die KDE komplett aufgesplittet haben und das ist der reinste Driss. Man weiss einfach nicht, was man installieren soll, und zwar genau dann, wenn man den Namen des Packages nicht kennt

Der derzeitige Ansatz ist nicht schlecht. Das Aufsplitten bringt neue Möglichkeiten, die alten sind weiterhin vorhanden:
emerge kde emerge kde-meta
emerge kdenetwork emerge kdenetwork-meta
emerge kdepim emerge kdepim-meta
usw.

IMHO wäre es sinnvoller, die USE Flags vielleicht auch auf KDE anzuwenden, vielleicht nicht mit den global use flags, dann eher mit KDE spezifischen USEFlags.
Die Sourcepackete muessen sowieso geladen werden, und z.B. ein

Code: Select all

KDE_USE="kdenetwork-kmail kdenetwork-knode kdegraphics-kprovray"

in der make.conf ist wesentlich eleganter als

Code: Select all

# emerge search kde-|less
# [...RESULT...]
# emerge <kde-package>

Noch eleganter wird es, wenn man aus dem komplett Packet div. virtuals machen könnte, um zum Beispiel: virtual/min-kde virtual/mid-kde virtual/max-kde virtual/gentoo-kde

Kein Problem. Pack ein "my-kde-3.3.1" ins OVERLAY mit folgendem Inhalt (aus dem Kopf)

Code: Select all

KEYWORDS="~x86"
DEPEND="kde-base/kdenetwork-meta
    kde-base/kdm
    kde-base/kde-i18n"

[shermann]

Der derzeitige Ansatz ist nicht schlecht. Das Aufsplitten bringt neue Möglichkeiten, die alten sind weiterhin vorhanden:
emerge kde emerge kde-meta
emerge kdenetwork emerge kdenetwork-meta
emerge kdepim emerge kdepim-meta
usw.

Es wird die Nutzer aber verwirren. Sie dir mal die ganzen RH MLs an...manche sind immer noch am verzweifeln (und nein, ich hab kein bock auf eine Diskussion wie "Gentoo is ja auch nich fuer LUser").

Wir sollten doch da innovativer sein

[Earthwings]

Das Projekt ist noch lange nicht abgeschlossen. Es spricht AFAIK nichts dagegen, für eine gewisse Zeit kdenetwork "Stub"-Ebuilds einzurichten, die nichts weiter machen, als kdenetwork-meta zu installieren. Volle Abwärtskompatibilität und minimale Verwirrung.

[Carlo]

shermann: Use Flags sind auch nicht der Weisheit letzter Schluß. Die Komplexität würde lediglich verlagert. Ob Ebuilds oder Use Flags verwendet werden (wobei letzteres definitiv die schlechtere Lösung wäre), ist dabei nicht von Belang.

Use Flags sind eh ein eigenes Thema: Bisher sind second-level dependencies (ist kdelibs mit arts use flag installiert worden, oder nicht?) nicht abbildbar. Außerdem verwirren sie die User in ihrer Vielzahl schon jetzt. Angedachte Lösungen, wie z.B. use Flag Groups, Prefixes und spezielle Profile haben alle ihre Problemchen.

Was die aufgesplitteten KDE Ebuilds angeht, bin ich auch gespannt. Ich denke, es wird aber immer Meta-Ebuilds geben, die den Paketen von kde.org entsprechen.

[shermann]

shermann: Use Flags sind auch nicht der Weisheit letzter Schluß. Die Komplexität würde lediglich verlagert. Ob Ebuilds oder Use Flags verwendet werden (wobei letzteres definitiv die schlechtere Lösung wäre), ist dabei nicht von Belang.

Dann bitte nenn mir doch mal die Nachteile?
Egal ob metas oder flags, bei einer Erweiterung der Core Packete müssen diese sowieso neu eingepflegt werden.
Das die USE Flags im Moment ein Desaster sind, ist durch div. nicht vorhandene Dokumentation auf dem laufenden System, richtig.

Use Flags sind eh ein eigenes Thema: Bisher sind second-level dependencies (ist kdelibs mit arts use flag installiert worden, oder nicht?) nicht abbildbar. Außerdem verwirren sie die User in ihrer Vielzahl schon jetzt. Angedachte Lösungen, wie z.B. use Flag Groups, Prefixes und spezielle Profile haben alle ihre Problemchen.

Gibts die Frage überhaupt ob ein packet mit useflag X oder useflag Y installiert worden ist?
Interessanter ist die Frage, wie kann ich die verwendeteten Libs nach der Installation erkennen (Abfrage mit LDD). Andere Frage, ist dies überhaupt so wichtig.

Aber anders, ich rede nicht von USE Flags die wichtig sein könnten für die Features, sondern ich rede von Flags die dazu gebraucht werden könnten, um aus einem "dicken" Packet nur bestimmte Dinge herrauszuholen.
Und wenn da dann Beispielsweise bei noatun oder amaroK arts gebraucht wird, und use arts nicht gesetzt ist, dann kann man darauf hinweisen. Egal ob Kdelibs nun mit arts oder -arts compiled und installiert wurde.

Wer weiter darüber diskutieren will, kann das in diesem Artikel tun:

Gentoo und KDE-Meta Ebuilds

Regards,
\sh

[Carlo]

Dann bitte nenn mir doch mal die Nachteile?

Falsche Verwendung von Use Flags. Sie sind dazu da Aspekte von Paketen abzubilden, nicht aber "Teilpakete".
Use Flag Hell

Gibts die Frage überhaupt ob ein packet mit useflag X oder useflag Y installiert worden ist?
Interessanter ist die Frage, wie kann ich die verwendeteten Libs nach der Installation erkennen (Abfrage mit LDD). Andere Frage, ist dies überhaupt so wichtig.

Ldd hilft nicht immer. Außerdem ist das Aufgabe der Entwickler. Langfristig sollen Ebuilds ja sämtliche Abhängigkeiten korrekt abbilden. Solche Spielereien wie die automatische Einbindung von Libs, wiewohl das entsprechende Use Flag negiert ist, müssen bisweilen dementsprechend gefixt werden. Und ja, die Frage gibt's und sie ist wichtig. Portage wird das in einer zukünftigen Version unterstützen.

[morbus]

Hi,
Ich wollte nur sagen, dass die KDE-Meta-Ebuilds bei mir schon sehr gut laufen

[shermann]

Dann bitte nenn mir doch mal die Nachteile?

Falsche Verwendung von Use Flags. Sie sind dazu da Aspekte von Paketen abzubilden, nicht aber "Teilpakete".
Use Flag Hell

Gut, wir reden hier aber immer noch von "to be compiled" Packeten.
Ich könnte es noch verstehen, auch wenn ich es pers. nicht mag, wenn die Binärpackete später in kleine Häppchen aufgeteilt werden, aber zur Compiletime ist dieses splitting einfach nur nervig.
Da ist es wesentlich einfacher, mit einem z.B. "KDE_USEAPP='...'" zu hantieren, und sich die zu verpackenden Häppchen aufzulösen, vielleicht mit dem gleichen Abfragesystem wie die der Useflags.

Gibts die Frage überhaupt ob ein packet mit useflag X oder useflag Y installiert worden ist?
Interessanter ist die Frage, wie kann ich die verwendeteten Libs nach der Installation erkennen (Abfrage mit LDD). Andere Frage, ist dies überhaupt so wichtig.

Ldd hilft nicht immer. Außerdem ist das Aufgabe der Entwickler. Langfristig sollen Ebuilds ja sämtliche Abhängigkeiten korrekt abbilden. Solche Spielereien wie die automatische Einbindung von Libs, wiewohl das entsprechende Use Flag negiert ist, müssen bisweilen dementsprechend gefixt werden. Und ja, die Frage gibt's und sie ist wichtig. Portage wird das in einer zukünftigen Version unterstützen.

Du meinst sicherlich solche Dinge wie z.B. bei PHP oder Apache mit DSOs.
Hier wird das entsprechend ja schon über UseFlags geregelt, und imho ist dies z.B. bei PHP5 eine nicht so gute Idee. Hier wäre eine abgeleitete, serparate Flag Behandlung wesentlich sinnvoller.

Aber nun gut, warten wir ab was kommt und was wird...

\sh

[Hotstuff]

Hallo

Welche Grundpackete braucht KDE. dass es leuft.

Gruss Dave

[sirro]

Welche Grundpackete braucht KDE. dass es leuft.

Wenn du den kompletten Desktop meinst, wuerde ich kdelibs und kdebase-meta sagen. Damit geht man auf Nummer sicher un installiert dann vom Rest nur das was man braucht.

[Hotstuff]

OK

Vielen Dank

Jo nur den Kde Bildschirm Oberfläche ohne die vielen Programmen

Gruss Dave

[Hotstuff]

Hallo

Ist das normal wen ich emerge kde-meta eingebe. Das ich noch 30 weiter Eintragen muss.

Grusss Dave

[Earthwings]

Was meinst du mit eintragen? In package.keywords? Ja. Oder >30 Abhängigkeiten? Ist auch normal, da kde-meta ja dem alten kde entspricht und somit *alle* aufgeteilten pakete installiert.

[Hotstuff]

Ok wollte nur sichergehen

Besten Dank

Gruss Dave

[ank666]

Hi,

bin gerade dabei 'nen Rechner neu zuinstallieren, d.h. ist noch kein Xorg und KDE drauf.

Habe jetzt Xorg 6.8 und kdebase-meta emergt,
hab jetzt erstmal ne ganze Weile gebraucht um raus zufinden warum kde nicht startet,
Grund kdebase-startkde wird nicht autom. mit gemergt,
das gehört aber (finde ich) schon mit ins Grundpaket!

So nächstes Phänomen, der Login Screen kommt, ich melde mich an,
der Bildschirm wird dunkel (vor dem inneren Auge kommt der KDE Desktop)
vor den echten Augen kommt wieder der Login Screen, geht immer so weiter.

Wieso grüßt mich täglich das Murmmeltier?

[Earthwings]

Habe jetzt Xorg 6.8 und kdebase-meta emergt,
hab jetzt erstmal ne ganze Weile gebraucht um raus zufinden warum kde nicht startet,
Grund kdebase-startkde wird nicht autom. mit gemergt,
das gehört aber (finde ich) schon mit ins Grundpaket!

Denke ich auch, poste das doch mal unter http://developer.berlios.de/mail/?group_id=2359
Wurde bisher noch nicht erwähnt dort.

So nächstes Phänomen, der Login Screen kommt, ich melde mich an,
der Bildschirm wird dunkel (vor dem inneren Auge kommt der KDE Desktop)
vor den echten Augen kommt wieder der Login Screen, geht immer so weiter.

Was sagen denn die logfiles?