kde-frameworks are seperate from the two. But kde-workspaces and kde-applications both reside in kde-base and have no means of being distinguished by portage. This can be a problem for dependencies. While it makes sense to let all dependencies inside kde-workspaces to be at least the version of the package having the dependency, this can be problematic for kde-applications. They don't yet have a release, which means that any dependency on kde-workspaces added using add_kdebase_dep will automatically pull in the git version, although that may not be necessary. Unless we want to add version numbers manually in these cases, we need a means of distinguishing between them. Already having kde-frameworks, the most logical choice would be to introduce the categories kde-workspaces (or kde-plasma or plasma-base or whatever) and kde-applications. kde-base would be kept only for KDE4 and eventually be removed when support for KDE4 ends. Reproducible: Always
Funny, this is almost identical to one proposal on the wiki. :-) We decided to delay the decision on whether to split kde-base or not until upstream's release plans become better defined. At the time, we would've struggled to justify a new kde-workspaces category due to the low number of packages (although this is slowly increasing as upstream shuffles things around). I believe we planned to revisit this once applications releases started happening. Even if we don't end up with a category split, we definitely will need some way to mark which packages are workspaces and which are applications to avoid those dependency issues.
We have the tree categories now, kde-frameworks, kde-plasma, and kde-apps.
