# 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 

```
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.

```

mkdir -p /usr/local/kde-meta

cd /usr/local

```

1. Möglichkeit: Herunterladen mit subversion

```

emerge -n subversion

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

```

Alternative: Dateien manuell herunterladen

```

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.

```

nano -w /etc/make.conf

```

Bei mir sieht das anschließend so aus:

```

[...]

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

[...]

```

Probieren, ob alles geklappt hat:

```
emerge knode -pv
```

Auf stabilen System sollte man eine derartige Fehlermeldung bekommen:

```

# 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:

```

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/20041115-newsletter.xml

TODO (für diesen Tipp)

- confcache

- prepackaged Makefiles

- xdeltas (Downloadmenge reduzieren)

----------

## sirro

 *Earthwings wrote:*   

> 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  :Wink: 

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

 *arlsair wrote:*   

> 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:

```
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

 *hothead wrote:*   

> 
> 
> 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

 *Earthwings wrote:*   

> 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

```

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

```

in der make.conf ist wesentlich eleganter als

```

# 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  :Smile: 

\sh

----------

## Earthwings

 *shermann wrote:*   

> 
> 
> 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  :Arrow:  emerge kde-meta

emerge kdenetwork  :Arrow:  emerge kdenetwork-meta

emerge kdepim  :Arrow:  emerge kdepim-meta

usw.

 *shermann wrote:*   

> 
> 
> 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
> ...

 

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

```

KEYWORDS="~x86"

DEPEND="kde-base/kdenetwork-meta

    kde-base/kdm

    kde-base/kde-i18n"

```

----------

## shermann

 *Earthwings wrote:*   

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

 

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  :Wink: 

----------

## 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

 *Carlo wrote:*   

> 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.

 *Carlo wrote:*   

> 
> 
> 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

 *shermann wrote:*   

> Dann bitte nenn mir doch mal die Nachteile?

 

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

 :Arrow:  Use Flag Hell

 *shermann wrote:*   

> 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  :Very Happy: 

----------

## shermann

 *Carlo wrote:*   

>  *shermann wrote:*   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.

 *Carlo wrote:*   

> 
> 
>  *shermann wrote:*   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. 
> ...

 

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

 *dave1986 wrote:*   

> 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  :Very Happy: 

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

 *ank666 wrote:*   

> 
> 
> Habe jetzt Xorg 6.8 und kdebase-meta emergt, 
> 
> hab jetzt erstmal ne ganze Weile gebraucht um raus zufinden warum kde nicht startet, 
> ...

 

Denke ich auch, poste das doch mal unter http://developer.berlios.de/mail/?group_id=2359

Wurde bisher noch nicht erwähnt dort.

 *Quote:*   

> 
> 
> 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) 
> ...

 

Was sagen denn die logfiles?

----------

## ank666

 *Earthwings wrote:*   

> Was sagen denn die logfiles?

 

Aus dem Gedächtnis, kdm sagt, dass der den Initial Greeting Screen nicht starten kann.

Genauere Logfiles liefere ich später nach, hab das Notebook im Moment nicht dabei.

----------

## Linuxpeter

Bei mir war das Problem, das ich kdebase-startkde zwar installiert hatte, die /usr/kde/3.3/startkde aber leer war.

Habe dann eben die startkde aus dem kdebase-Tarball reinkopiert.

Jetzt muß ich bloß noch rauskriegen, welches meta-ebuild für das Panel zuständig ist.   :Rolling Eyes: 

----------

## Carlo

 *Linuxpeter wrote:*   

> Jetzt muß ich bloß noch rauskriegen, welches meta-ebuild für das Panel zuständig ist.  

 

Welches Panel? Meinst Du Kicker?

----------

## Linuxpeter

Ja Carlo, habs mittlerweile auch festgestellt   :Wink: 

----------

## morbus

Hi,

nur mal interessehalber: Weiß jemand, wann die kde-3.2.2 pakete in diesen tree kommen?

----------

## ank666

Danke, die startkde war wirklich leer!

Nächste Frage, wie kann ich das ganze jetzt eindeutschen, wenn ich i18-n emergen will,

das zieht das kdebase mit sich, ein i18-n-meta hab ich nicht gefunden.

[EDIT]

k3b und amarok merken übrigens auch nix von der installierten kdebase-meta, 

kann ich es ihnen irgendwie klar machen, das die meta-base installiert ist und sie deshalb die normale gar nicht mehr brauchen?

----------

## morbus

Also, die 3.3.2 pakete sind jetzt da  :Wink: 

----------

## Linuxpeter

Versuch mal mit 

```

$ emerge --oneshot --nodeps k3b

```

Alle anderen Abhängigkeiten sollten aber schon erledigt sein.

----------

## ank666

Nochmal Dankeschön an Linuxpeter, wollte es evtl. mit --inject versuchen, aber das ist wohl auch nicht so das Wahre.

----------

## morbus

Hi,

Da ich gerne ein stable-System habe, fand ich es nervig, immer nachzukucken, welche ungesplittete kde-Version denn gerade stable war. Also habe ich mir ein quick'n'dirty-Skript geschriebe, dem der Programmname (also z.B. kaboodle) übergeben wird, das dann nachschaut, zu welchem Paket das gehört, ausprobiert, welche Version portage von dem originalen ebuild installieren würde und dann die portage.keywords anpasst (also in meinem Fall =kde-base/kaboodle-3.3.1 ~x86) hinzufügt.

Vielleicht nützt es ja jemandem...

```

#!/bin/bash

#written by M.Reincke (mreincke@gmx.net)

#The kde-overly-directory

OPATH='/usr/local/portage/kde-base/'

#it's quite annoying, but we need this to grep KMNAME. 3.3.1 is the only version (in my tree)

#such that for every package exists an ebuild with this. You may change this value...

PV=3.3.1

NAME=$1

export `grep KMNAME $OPATH$NAME/$NAME-$PV.ebuild`

#bash doesn't like me so I need a temp-file

emerge -pO $KMNAME > temp

LAST_VER=`grep $KMNAME temp`

rm temp

#cut down to the version...

LAST_VER=`echo $LAST_VER | sed 's/\[ebuild N ] //'`

LAST_VER=`echo $LAST_VER | sed 's/kde-base\///'`

LAST_VER=`echo $LAST_VER | sed -e 's/k[^\-]*\-//g'`

#Add it to /etc/portage/package.keywords

echo "#Added by update-keyword" >> /etc/portage/package.keywords

echo "=kde-base/$NAME-$LAST_VER ~x86" >> /etc/portage/package.keywords

```

----------

