# Wie kde-base/kdm trotz Blocked Packages emergen? [solved]

## 3PO

Wie kann ich kdm emergen totz der vielen Blocked Packages emergen.

Bevor es jetzt losgeht mit "benutze die Suchfunktion" oder Google, möchte vorwegnehmen das ich da schon gesucht habe.

Ich habe auch schon versucht alle Blocked Packages zu unmergen leider ohne Erfolg.

Im Prinzip war das ja auch Blödsinn alles zu entfernen was ich eigentlich mit kdm starten wollte, oder??

Hat Jemand eine Idee wie ich das Problem umschiffen kann?

```
vdr01 ~ # emerge -av kdm

These are the packages that would be merged, in order:

Calculating dependencies... done!

[ebuild  N    ] kde-base/libkonq-3.5.5  USE="xinerama -arts -debug -kdeenablefinal -kdehiddenvisibility" 0 kB

[ebuild  N    ] kde-base/kdebase-data-3.5.5  USE="xinerama -debug -kdeenablefinal" 0 kB

[ebuild  N    ] kde-base/kdialog-3.5.5  USE="xinerama -arts -debug -kdeenablefinal -kdehiddenvisibility" 0 kB

[ebuild  N    ] kde-base/khelpcenter-3.5.5  USE="xinerama -arts -debug -kdeenablefinal -kdehiddenvisibility" 0 kB

[ebuild  N    ] kde-base/kdesu-3.5.5  USE="xinerama -arts -debug -kdeenablefinal -kdehiddenvisibility" 0 kB

[ebuild  N    ] kde-base/kcminit-3.5.3  USE="xinerama -arts -debug -kdeenablefinal -kdehiddenvisibility" 0 kB

[ebuild  N    ] kde-base/khotkeys-3.5.5  USE="xinerama -arts -debug -kdeenablefinal -kdehiddenvisibility" 0 kB

[ebuild  N    ] kde-base/kcheckpass-3.5.0  USE="pam xinerama -arts -debug -kdeenablefinal -kdehiddenvisibility -kdexdeltas" 0 kB

[ebuild  N    ] kde-base/kicker-3.5.5  USE="xinerama -arts -debug -kdeenablefinal -kdehiddenvisibility -xcomposite" 0 kB

[ebuild  N    ] kde-base/kdepasswd-3.5.5  USE="xinerama -arts -debug -kdeenablefinal -kdehiddenvisibility" 0 kB

[ebuild  N    ] kde-base/kfind-3.5.5  USE="xinerama -arts -debug -kdeenablefinal -kdehiddenvisibility" 0 kB

[ebuild  N    ] kde-base/kdebase-kioslaves-3.5.5-r1  USE="samba xinerama -arts -debug -hal -kdeenablefinal -kdehiddenvisibility -ldap -openexr" 0 kB

[ebuild  N    ] kde-base/kcontrol-3.5.5  USE="opengl ssl xinerama -arts -debug -ieee1394 -kdeenablefinal -kdehiddenvisibility -logitech-mouse" 0 kB

[ebuild  N    ] kde-base/kdm-3.5.5-r1  USE="pam xinerama -arts -debug -kdeenablefinal -kdehiddenvisibility" 0 kB

[ebuild  N    ] kde-base/konqueror-3.5.5  USE="java xinerama -arts -debug -kdeenablefinal -kdehiddenvisibility" 0 kB

[ebuild  N    ] kde-base/kdesktop-3.5.5-r1  USE="xinerama -arts -debug -kdeenablefinal -kdehiddenvisibility -xscreensaver" 0 kB

[blocks B     ] =kde-base/kicker-3.5* (is blocking kde-base/kdebase-3.5.5-r3)

[blocks B     ] =kde-base/kfind-3.5* (is blocking kde-base/kdebase-3.5.5-r3)

[blocks B     ] =kde-base/kdm-3.5* (is blocking kde-base/kdebase-3.5.5-r3)

[blocks B     ] =kde-base/libkonq-3.5* (is blocking kde-base/kdebase-3.5.5-r3)

[blocks B     ] =kde-base/kdebase-3.5* (is blocking kde-base/kdepasswd-3.5.5, kde-base/kcontrol-3.5.5, kde-base/kdebase-data-3.5.5, kde-base/kdm-3.5.5-r1, kde-base/libkonq-3.5.5, kde-base/khelpcenter-3.5.5, kde-base/khotkeys-3.5.5, kde-base/kdesktop-3.5.5-r1, kde-base/kcheckpass-3.5.0, kde-base/kdialog-3.5.5, kde-base/kcminit-3.5.3, kde-base/konqueror-3.5.5, kde-base/kdebase-kioslaves-3.5.5-r1, kde-base/kfind-3.5.5, kde-base/kicker-3.5.5, kde-base/kdesu-3.5.5)

[blocks B     ] =kde-base/kcminit-3.5* (is blocking kde-base/kdebase-3.5.5-r3)

[blocks B     ] =kde-base/kdesktop-3.5* (is blocking kde-base/kdebase-3.5.5-r3)

[blocks B     ] =kde-base/konqueror-3.5* (is blocking kde-base/kdebase-3.5.5-r3)

[blocks B     ] =kde-base/kdebase-data-3.5* (is blocking kde-base/kdebase-3.5.5-r3)

[blocks B     ] =kde-base/kcheckpass-3.5* (is blocking kde-base/kdebase-3.5.5-r3)

[blocks B     ] =kde-base/kdebase-kioslaves-3.5* (is blocking kde-base/kdebase-3.5.5-r3)

[blocks B     ] =kde-base/kdialog-3.5* (is blocking kde-base/kdebase-3.5.5-r3)

[blocks B     ] =kde-base/kdepasswd-3.5* (is blocking kde-base/kdebase-3.5.5-r3)

[blocks B     ] =kde-base/kcontrol-3.5* (is blocking kde-base/kdebase-3.5.5-r3)

[blocks B     ] =kde-base/khelpcenter-3.5* (is blocking kde-base/kdebase-3.5.5-r3)

[blocks B     ] =kde-base/khotkeys-3.5* (is blocking kde-base/kdebase-3.5.5-r3)

[blocks B     ] =kde-base/kdesu-3.5* (is blocking kde-base/kdebase-3.5.5-r3)

Total: 16 packages (16 new, 17 blocks), Size of downloads: 0 kB

!!! Error: The above package list contains packages which cannot be installed

!!!        at the same time on the same system.

For more information about Blocked Packages, please refer to the following

section of the Gentoo Linux x86 Handbook (architecture is irrelevant):

http://www.gentoo.org/doc/en/handbook/handbook-x86.xml?full=1#blocked

vdr01 ~ #
```

Last edited by 3PO on Wed Apr 11, 2007 7:51 pm; edited 1 time in total

----------

## franzf

Du hast kdebase und damit auch kdm schon drauf. Einfach in deiner /etc/rc.conf eintragen und fertig.

Grüße

Franz

----------

## 3PO

 *franzf wrote:*   

> Du hast kdebase und damit auch kdm schon drauf. Einfach in deiner /etc/rc.conf eintragen und fertig.
> 
> Grüße
> 
> Franz

 

Laut eix aber nicht?

```
vdr01 ~ # eix kde-base/kdm

* kde-base/kdm

     Available versions:  (3.5)  3.5.5-r1 ~3.5.6

     Homepage:            http://www.kde.org/

     Description:         KDE login manager, similar to xdm and gdm

vdr01 ~ #

```

Aber Du hast recht, es geht.

Danke für den Tip   :Very Happy: 

----------

## giga89

Du hast wahrscheinlich damals kdebase oder ähnliches installiert und nicht kdebase-meta.

KDE ist mittlerweile gesplitted in viele einzelne Pakete.

Ein emerge kdebase-meta hätte das einzelne Paket kdm installiert, während ein emerge kdebase kdm beinhaltet.

Ich finds komisch, dass immer noch beide Möglichkeiten bestehen...

----------

## franzf

 *giga89 wrote:*   

> Du hast wahrscheinlich damals kdebase oder ähnliches installiert und nicht kdebase-meta.
> 
> KDE ist mittlerweile gesplitted in viele einzelne Pakete.
> 
> Ein emerge kdebase-meta hätte das einzelne Paket kdm installiert, während ein emerge kdebase kdm beinhaltet.
> ...

 

Noch komischer find ich, dass für kde4 eigentlich angekündigt wurde, dass man nur noch die split-ebuilds bekommt, im overlay (layman -a kde) aber nur monolithische zu haben sind...

----------

## a.forlorn

Und ich bin bei allen meinen PCs gerade von split auf monolith umgestiegen.  :Wink:  Achso, die snapshots liegen nur als die üblichen verdächtigen monoliths vor.  :Wink: 

Nebenbei: kdebase compiliert viel schneller als kdebase-meta. Warum sollte ich also den langen Weg nehmen, wenn ich eh alles haben will?

----------

## nikaya

 *a.forlorn wrote:*   

> 
> 
> Nebenbei: kdebase compiliert viel schneller als kdebase-meta. Warum sollte ich also den langen Weg nehmen, wenn ich eh alles haben will?

 

Ist das so?Kompiliert kdebase schneller als kdebase-meta?

Nur so aus Interesse.Der Inhalt ist doch eigentlich gleich,nur dass das meta-package Teile aus dem kdebase-tarball immer gesondert extrahiert.

----------

## giga89

Einen einzelnen emerge-Prozess zu starten ist viel kürzer als viele kleine, die ganze Konfigurationsüberprüfung ist dann ja oft doppelt gemacht.

----------

## nikaya

 *giga89 wrote:*   

> Einen einzelnen emerge-Prozess zu starten ist viel kürzer als viele kleine, die ganze Konfigurationsüberprüfung ist dann ja oft doppelt gemacht.

 

Das ist klar,ich war jetzt von der reinen Kompilation ausgegangen.

Ok,erledigt.  :Wink: 

----------

## franzf

 *giga89 wrote:*   

> Einen einzelnen emerge-Prozess zu starten ist viel kürzer als viele kleine, die ganze Konfigurationsüberprüfung ist dann ja oft doppelt gemacht.

 

Darum steigen die KDE-Developer jetzt auf cmake um. Das lässt sich da besser managen.

----------

## tgurr

 *franzf wrote:*   

> Noch komischer find ich, dass für kde4 eigentlich angekündigt wurde, dass man nur noch die split-ebuilds bekommt, im overlay (layman -a kde) aber nur monolithische zu haben sind...

 

Das liegt leider daran, dass KDE4 (zumindest im Moment) leider sehr split-unfreundlich ist und cmake die Sache in der Hinsicht nicht wirklich einfacher macht. Prioritäten des Overlays liegen erstmal wie folgt:

Ebuilds für KDE4 Snapshots monolithisch - fertig

Ebuilds für KDE4 SVN monolithisch - fertig

Ebuilds für KDE4 Snapshots splitted - in Arbeit

Ebuilds für KDE4 SVN splitted - erst nachdem das Splitten der Snapshots funktioniert hat

Würde aber davon abraten KDE4 aus dem Overlay neben KDE3 zu installieren.

----------

## franzf

 *Psy' wrote:*   

> Ebuilds für KDE4 Snapshots monolithisch - fertig
> 
> Ebuilds für KDE4 SVN monolithisch - fertig
> 
> Ebuilds für KDE4 Snapshots splitted - in Arbeit
> ...

 

Hört sich ja fast so an als wärst du richtig im Development involviert  :Smile: 

Leider kann ich das kde4 nicht installieren, da es (zumindest bei meinen letzten Versuchen) die doofe Abhängigkeit <virtual/x11-7.0 drinnen hatte, was bei der momentanen Lage (keine ebuilds zu <xorg-7.0, z.m. im offiziellen Portage) einfach nicht zu realisieren ist  :Smile: 

Interessiert hätte es mich allemal, da ich eh momentan viel mit qt4 mach, und in sourcen schnüffeln, vor allem von einem so komplexen Projekt, immer interessant ist (nur wenn ich es auch installieren kann und evtl. Bugs reporten  :Wink: ).

Grüße

Franz

----------

## Carlo

 *franzf wrote:*   

> Noch komischer find ich, dass für kde4 eigentlich angekündigt wurde, dass man nur noch die split-ebuilds bekommt, im overlay (layman -a kde) aber nur monolithische zu haben sind...

 

Ich kann dir nicht mal sagen, wer das Overlay macht, geschweige denn geguckt wie man mögichst automatisiert die CMake Buildskripte parst und daraus die gesplitteten Ebuilds erstellt...

----------

## Philantrop

Folgendes ist der Stand:

- Das layman-Overlay "kde" wird von Zephyrus, Psy und mir selbst betreut. Es enthält ebuilds für die monolithischen KDE-Pakete für den Snapshot 3.80.3 und Live-SVN-Ebuilds. Abhängigkeiten auf virtual/x11 sind darin nicht enthalten.

Siehe https://forums.gentoo.org/viewtopic-t-530111-highlight-kde4.html für Detail-Informationen.

- Es existiert ein weiteres Overlay, in dem wir Split-Ebuilds für den 3.80.3-Snapshot und Live-SVN-Ebuilds erstellen. Dieses ist momentan bewußt nicht in layman enthalten.

Ich sehe leider wenig Möglichkeiten, automatisiert die Split-Ebuilds zu erzeugen, da sich das Splitting momentan, IMHO, noch schwieriger gestaltet als bei KDE3. 

Wer ich nun wieder bin? Ich arbeitete in der Vergangenheit primär am KDE3-Live-SVN-Overlay und habe dann mit KDE4 begonnen. Parallel hat das auch Zephyrus getan. Durch die Vermittlung von genstef kamen wir zusammen und haben beschlossen, dieses Projekt gemeinsam fortzusetzen.

----------

## Klaus Meier

 *a.forlorn wrote:*   

> Nebenbei: kdebase compiliert viel schneller als kdebase-meta. Warum sollte ich also den langen Weg nehmen, wenn ich eh alles haben will?

 

Weil du dann später, wenn in einem Paket ein Fehler behoben wurde, 2 Stunden kompilierst. Und derjenige mit den split-ebuilds nur 10 Minuten.

----------

## a.forlorn

Mhm, und wann war das mal der Fall? Außer bei Kopete wegen dem ICQ-Protokoll.

----------

## Klaus Meier

 *a.forlorn wrote:*   

> Mhm, und wann war das mal der Fall? Außer bei Kopete wegen dem ICQ-Protokoll.

 

Gestern. Siehe http://www.gentoo-portage.com/Newest/%7Ex86

----------

## a.forlorn

 *Klaus Meier wrote:*   

>  *a.forlorn wrote:*   Mhm, und wann war das mal der Fall? Außer bei Kopete wegen dem ICQ-Protokoll. 
> 
> Gestern. Siehe http://www.gentoo-portage.com/Newest/%7Ex86

 

Bei stable außer kdelibs neulich schon seit einer ganzen Weile nicht mehr. Also: stable = monolith, testing = meta!  :Wink: 

----------

## Klaus Meier

 *a.forlorn wrote:*   

>  *Klaus Meier wrote:*    *a.forlorn wrote:*   Mhm, und wann war das mal der Fall? Außer bei Kopete wegen dem ICQ-Protokoll. 
> 
> Gestern. Siehe http://www.gentoo-portage.com/Newest/%7Ex86 
> 
> Bei stable außer kdelibs neulich schon seit einer ganzen Weile nicht mehr. Also: stable = monolith, testing = meta! 

 

Ich fands bei dir halt so lustig, weil du dein System von Split auf Monolytisch umgestellt hast. Also weil die Neuinstallation schneller ist und die Updates langsamer, deshalb hast du ein bestehendes System auf Monolytisch umgestellt. Also du kompilierst da jetzt so nen halben Tag oder nen ganzen rum, damit die Updates länger dauern. Erklär es mir bitte, ich verstehe es einfach nicht.

----------

## a.forlorn

Ich hab 3.5.5. Wenn 3.5.6 stable wird, sind auch wieder alle monolith schneller gebaut als 3.5.6-meta. Einfach mal testen. Und da ich viel seltener ein update habe, lohnt sich das imo.

----------

## Finswimmer

Noch ist monolith schneller, die wollen aber KDE4 nur noch split Pakete rausbringen. Und der configure soll dann nur einmal durchlaufen.

Dann hat man von der emerge Zeit keinen Nachteil mehr bei den splits, dafür aber den riesen Vorteil, dass man

1) nur das hat, was man braucht

2) Updates (Security-Fixes) von einzelnen Komponenten erheblich schneller sind

Tobi

----------

## Klaus Meier

 *a.forlorn wrote:*   

> Ich hab 3.5.5. Wenn 3.5.6 stable wird, sind auch wieder alle monolith schneller gebaut als 3.5.6-meta. Einfach mal testen. Und da ich viel seltener ein update habe, lohnt sich das imo.

 

Das mag ja alles sein, aber ich verstehe trotzdem nicht, warum du bestehende Systeme umgestellt hast. Wenn du das beim Wechsel von 3.5.5 auf 3.5.6 gemacht hättest, ok. KDE 3.5.6 ist es beim Installieren egal, ob das 3.5.5 monolytisch oder als split vorlag.

----------

## Philantrop

 *Finswimmer wrote:*   

> die wollen aber KDE4 nur noch split Pakete rausbringen.

 

Sofern "die" die Gentoo-Devs sind, wäre mir das neu. :-)

----------

## Finswimmer

 *Philantrop wrote:*   

>  *Finswimmer wrote:*   die wollen aber KDE4 nur noch split Pakete rausbringen. 
> 
> Sofern "die" die Gentoo-Devs sind, wäre mir das neu. 

 

Ich meinte die KDE Devs. Im Moment wird 3.5 ja noch in beiden Varianten angeboten, was dann ab 4 sich ändern soll.

Tobi

----------

## a.forlorn

Weil es dann trotzdem zu [blocks] kommt, dem wollte ich einfach vorbeugen (ich muss es eh irgendwann machen). Bei 3.4 zu 3.5 stimm ich zu, bei 3.5.x zu 3.5.y nicht. Bei meta hast du halt noch Programme, die 3.5.0 oder 3.5.2 sind, wenn man dann auf monolith umsteigt, klappt das so nicht.

edit: ich freu mich schon auf 4, sieht ganz nett aus von den previews. Ob dann wirklich nur split rauskommen, oder nicht werden wir sehen. Die Frage ist, ob es dann auch tausend split Archive gibt, oder wieder die riesigen wie jetzt. Falls es die großen packages weiterhin gibt, bastel ich mir KDE dann trotzdem als monolith. KDE in seiner ganzen Schönheit kann man imo nur vollständig genießen.  :Wink: 

----------

## Philantrop

 *Finswimmer wrote:*   

>  *Philantrop wrote:*    *Finswimmer wrote:*   die wollen aber KDE4 nur noch split Pakete rausbringen. 
> 
> Sofern "die" die Gentoo-Devs sind, wäre mir das neu. :-) 
> 
> Ich meinte die KDE Devs. Im Moment wird 3.5 ja noch in beiden Varianten angeboten, was dann ab 4 sich ändern soll.

 

Nein, ich arbeite u. a. an den KDE4-ebuilds und wir haben bereits monolithische Ebuilds und ich habe nicht vor, die wegzuwerfen. :-)

Sofern also nicht die kde-herd, zu der auch ich gehöre, gemeinsam doch noch etwas anderes beschließt, wird es auch weiterhin die monolithischen Pakete geben.

----------

## a.forlorn

Danke.  :Very Happy:  Ich find die halt praktischer.

----------

## Finswimmer

 *Philantrop wrote:*   

>  *Finswimmer wrote:*    *Philantrop wrote:*    *Finswimmer wrote:*   die wollen aber KDE4 nur noch split Pakete rausbringen. 
> 
> Sofern "die" die Gentoo-Devs sind, wäre mir das neu.  
> 
> Ich meinte die KDE Devs. Im Moment wird 3.5 ja noch in beiden Varianten angeboten, was dann ab 4 sich ändern soll. 
> ...

 

Hmm. Ok. Dann habe ich damals was falsch verstanden, oder die Seite, von der ich das habe.

Tobi

----------

## Klaus Meier

 *Finswimmer wrote:*   

> Hmm. Ok. Dann habe ich damals was falsch verstanden, oder die Seite, von der ich das habe.
> 
> Tobi

 

Hast du nicht. Auf http://www.gentoo.org/doc/en/kde-split-ebuilds.xml steht: 

```
We still provide monolithic ebuilds for 3.5 and they are cleanly interoperable with the split ones. However, the split ebuilds are the new default, and there will be no monolithic ebuilds for KDE 4.0.
```

----------

## Philantrop

 *Klaus Meier wrote:*   

>  *Finswimmer wrote:*   Hmm. Ok. Dann habe ich damals was falsch verstanden, oder die Seite, von der ich das habe.
> 
> Tobi 
> 
> Hast du nicht. Auf http://www.gentoo.org/doc/en/kde-split-ebuilds.xml steht: 
> ...

 

Danke für den Hinweis! Wird geändert.

----------

## Finswimmer

 *Philantrop wrote:*   

>  *Klaus Meier wrote:*    *Finswimmer wrote:*   Hmm. Ok. Dann habe ich damals was falsch verstanden, oder die Seite, von der ich das habe.
> 
> Tobi 
> 
> Hast du nicht. Auf http://www.gentoo.org/doc/en/kde-split-ebuilds.xml steht: 
> ...

 

Ha. Danke Klaus, ich hab schon an meinem Gehirn gezweifelt.

Aber ich finde es gut, dass es trotzdem beides geben wird. Soll doch jeder machen wie er mag  :Smile: 

Tobi

----------

## nikaya

 *Finswimmer wrote:*   

> 
> 
> Aber ich finde es gut, dass es trotzdem beides geben wird. Soll doch jeder machen wie er mag 
> 
> 

 

Nachteil:Es wird jedoch weiterhin Threads wie diesen geben wegen [blocked packages].Ist ja aber meistens schnell behoben.  :Smile: 

Es wäre schön wenn die Unterschiede modular -> monolithisch in den Paketnamen zukünftig deutlicher erkennbar wären.Also z.B. "kde-base/kde-meta" und "kde-base/kde-full".Name wäre letztendlich egal.Gerade Neulinge geben schnell "emerge kde" ein um dann später festzustellen das sie doch lieber die Split-Ebuilds installiert hätten.

----------

## Finswimmer

 *john.doe wrote:*   

>  *Finswimmer wrote:*   
> 
> Aber ich finde es gut, dass es trotzdem beides geben wird. Soll doch jeder machen wie er mag 
> 
>  
> ...

 

Das kann man ja auch umgehen, indem man die beliebtere Alternative als Standard unter "emerge kde" setzt, und das Andere halt mehr "Aufwand" ist.

Tobi

----------

## Klaus Meier

 *Finswimmer wrote:*   

> Das kann man ja auch umgehen, indem man die beliebtere Alternative als Standard unter "emerge kde" setzt, und das Andere halt mehr "Aufwand" ist.
> 
> Tobi

 

Theoretisch richtig. Ich freue mich dann schon auf die Diskussionen, wenn festgelegt wird, welches die beliebtere ist.

----------

## Max Steel

Also ich habe erst auch kde installieren wollen und nicht kde-meta, bis mich ein Freund darauf hingewiesen das die blocked Packages auf installierte kdeteile hinweisen die den eigentlich kde blocken.

Aber warum kdebase-meta und nicht gleich kde-meta,

ok, dann kan man sich selber alles zusammenwürfeln,

aber klärt mich mal auf, warum kdebase-meta und nicht kde-meta.

Weil ich weiß nicht, warum ich mir alles selber zusammenwürfeln möchte, wenn ich schon alles, mit etwas zusätzlich, installieren kann.

vll. bin ich für eure Variante auh einfach zu faul.

@Mod#

Ich würde dann mal sagen das diese Diskusion ob KDE4 mit oder ohne Splits (,oder so), abgetrennt wird.

Wenn aus diesem Thread hier auch eine Diskussion wird, kannste sie auch abtrennen.

----------

## nikaya

 *Max Steel wrote:*   

> 
> 
> Aber warum kdebase-meta und nicht gleich kde-meta,
> 
> ok, dann kan man sich selber alles zusammenwürfeln,
> ...

 

Zwischen kdebase-meta und kde-meta ist ein großer Unterschied.

kdebase-meta installiert die wichtigsten KDE-Komponenten.OK,es gibt auch noch kdebase-startkde das ist aber wirklich das minimalste.Danach kann man modulare KDE Pakete nach Bedarf nachinstallieren.

kde-meta installiert das volle KDE,also alles was "emerge kde" auch installieren würde.Nur mit dem Unterschied dass dieses mit Split-Ebuilds installiert würde.Du kannst danach also einzelne Pakete wieder löschen,welches bei "emerge kde" nicht möglich ist.Dort kann man nur die großen Pakete installieren/löschen,wie z.B. kdeadmin,kdeartwork,kdepim,kdegraphics usw.

----------

## a.forlorn

Wie wäre es denn mit:

```
emerge kde-split
```

und

```
emerge kde-monolith
```

?

Meiner Meinung nach logischer als nur "kde" oder "kde-meta".

----------

## nikaya

Namen wären letztendlich ziemlich egal,sollten natürlich intuitiv sein.Für die monolithischen Pakete würde ich aber auch einen Zusatz befürworten.

----------

